介紹zk一些入門概念，重點(diǎn)講解zab的消息廣播以及崩潰恢復(fù)，進(jìn)而衍生出一些拓展的思考以及橫向?qū)Ρ?/p>

簡(jiǎn)介：

https://zh.wikipedia.org/wiki/Apache_ZooKeeper#cite_note-1

http://zookeeper.apache.org/doc/current/zookeeperOver.html

CAP中的CP，沒(méi)有A
CAP：https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86

image

全量數(shù)據(jù)放在內(nèi)存中，qps級(jí)別在10w

概念

節(jié)點(diǎn)角色

Leader:僅一臺(tái)，通過(guò)選舉完成，提供讀寫服務(wù)
Follower:參與Leader選舉以及"過(guò)半寫成功"策略，提供讀服務(wù)
Observer:僅提供讀服務(wù),不參與選舉以及過(guò)半寫成功

節(jié)點(diǎn)狀態(tài):

`LOOKING：當(dāng)前Server不知道leader是誰(shuí)，正在搜尋`
`LEADING：當(dāng)前Server即為選舉出來(lái)的leader`
`FOLLOWING：leader已經(jīng)選舉出來(lái)，當(dāng)前Server與之同步`

會(huì)話：

Session是指客戶端會(huì)話，在講解客戶端會(huì)話之前，我們先來(lái)了解下客戶端連接。在ZooKeeper中，一個(gè)客戶端連接是指客戶端和ZooKeeper服務(wù)器之間的TCP長(zhǎng)連接。ZooKeeper對(duì)外的服務(wù)端口默認(rèn)是2181，客戶端啟動(dòng)時(shí)，首先會(huì)與服務(wù)器建立一個(gè)TCP連接，從第一次連接建立開始，客戶端會(huì)話的生命周期也開始了，通過(guò)這個(gè)連接，客戶端能夠通過(guò)心跳檢測(cè)和服務(wù)器保持有效的會(huì)話，也能夠向ZooKeeper服務(wù)器發(fā)送請(qǐng)求并接受響應(yīng)，同時(shí)還能通過(guò)該連接接收來(lái)自服務(wù)器的Watch事件通知。Session的SessionTimeout值用來(lái)設(shè)置一個(gè)客戶端會(huì)話的超時(shí)時(shí)間。當(dāng)由于服務(wù)器壓力太大、網(wǎng)絡(luò)故障或是客戶端主動(dòng)斷開連接等各種原因?qū)е驴蛻舳诉B接斷開時(shí)，只要在SessionTimeout規(guī)定的時(shí)間內(nèi)能夠重新連接上集群中任意一臺(tái)服務(wù)器，那么之前創(chuàng)建的會(huì)話仍然有效。

數(shù)據(jù)：

Zookeeper樹結(jié)構(gòu)

Zookeeper提供基于類似于文件系統(tǒng)的目錄節(jié)點(diǎn)樹方式的數(shù)據(jù)存儲(chǔ)，但是在分布式系統(tǒng)中，Zookeeper并不是用來(lái)存儲(chǔ)數(shù)據(jù)的，每個(gè)節(jié)點(diǎn)的數(shù)據(jù)最大不能超過(guò)1MB，它的作用主要是用來(lái)維護(hù)和監(jiān)控這些數(shù)據(jù)的變化的，通過(guò)監(jiān)控這些數(shù)據(jù)的變化，就可以達(dá)到基于數(shù)據(jù)的集群管理。

image

Zookeeper的數(shù)據(jù)節(jié)點(diǎn)稱為ZNode，ZNode是Zookeeper中數(shù)據(jù)的最小單元，每個(gè)ZNode都可以保存數(shù)據(jù)，同時(shí)還可以掛載子節(jié)點(diǎn)，因此構(gòu)成了一個(gè)層次化的命名空間，稱為樹。

數(shù)據(jù)節(jié)點(diǎn)

ZooKeeper 節(jié)點(diǎn)是有生命周期的，這取決于節(jié)點(diǎn)的類型。在 ZooKeeper 中，節(jié)點(diǎn)類型可以分為持久節(jié)點(diǎn)（PERSISTENT ）、臨時(shí)節(jié)點(diǎn)（EPHEMERAL），以及時(shí)序節(jié)點(diǎn)（SEQUENTIAL ），具體在節(jié)點(diǎn)創(chuàng)建過(guò)程中，一般是組合使用，可以生成以下 4 種節(jié)點(diǎn)類型。

`持久節(jié)點(diǎn)（PERSISTENT）`
`持久順序節(jié)點(diǎn)（PERSISTENT_SEQUENTIAL）`
`臨時(shí)節(jié)點(diǎn)（EPHEMERAL）`
`臨時(shí)順序節(jié)點(diǎn)（EPHEMERAL_SEQUENTIAL）`

|

image

上圖描述了一個(gè)持久順序節(jié)點(diǎn)

節(jié)點(diǎn)描述Stat

ZooKeeper命名空間中的每個(gè)znode都有一個(gè)與之關(guān)聯(lián)的stat結(jié)構(gòu)，類似于Unix/Linux文件系統(tǒng)中文件的stat結(jié)構(gòu)。 znode的stat結(jié)構(gòu)中的字段顯示如下，各自的含義如下：

`cZxid：這是導(dǎo)致創(chuàng)建znode更改的事務(wù)ID。`
`mZxid：這是最后修改znode更改的事務(wù)ID。`
`pZxid：這是用于添加或刪除子節(jié)點(diǎn)的znode更改的事務(wù)ID。`
`ctime：表示從1970-01-01T00:00:00Z開始以毫秒為單位的znode創(chuàng)建時(shí)間`
`mtime：表示從1970-01-01T00:00:00Z開始以毫秒為單位的znode最近修改時(shí)間。`
`dataVersion：表示對(duì)該znode的數(shù)據(jù)所做的更改次數(shù)。`
`cversion：這表示對(duì)此znode的子節(jié)點(diǎn)進(jìn)行的更改次數(shù)。`
`aclVersion：表示對(duì)此znode的ACL進(jìn)行更改的次數(shù)。`
`ephemeralOwner：如果znode是ephemeral類型節(jié)點(diǎn)，則這是znode所有者的 session ID。 如果znode不是ephemeral節(jié)點(diǎn)，則該字段設(shè)置為零。`
`dataLength：這是znode數(shù)據(jù)字段的長(zhǎng)度。`
`numChildren：這表示znode的子節(jié)點(diǎn)的數(shù)量。`

版本

其中，version，cversion，aversion合稱為版本

基于樂(lè)觀鎖的寫入校驗(yàn)

Client 功能:

`create `
`ls`
`get`
`set`
`delete`
`exists`

image

image

image

watch機(jī)制

ZooKeeper允許客戶端向服務(wù)端注冊(cè)感興趣的Watcher監(jiān)聽(tīng)，當(dāng)服務(wù)端觸發(fā)了這個(gè)Watcher，那么就會(huì)向客戶端發(fā)送一個(gè)時(shí)間來(lái)實(shí)現(xiàn)分布式的通知功能。真正的Watcher回調(diào)與業(yè)務(wù)邏輯執(zhí)行都在客戶端

推拉結(jié)合,推：通知，但是不告訴最新值，拉：拉最新值

image

特性

| 特性 | 說(shuō)明 |
| 一次性 | Watcher是一次性的，一旦被觸發(fā)就會(huì)移除，再次使用時(shí)需要重新注冊(cè) |
| 客戶端順序回調(diào) | Watcher回調(diào)是順序串行化執(zhí)行的，只有回調(diào)后客戶端才能看到最新的數(shù)據(jù)狀態(tài)。一個(gè)Watcher回調(diào)邏輯不應(yīng)該太多，以免影響別的watcher執(zhí)行 |
| 輕量級(jí) | WatchEvent是最小的通信單元，結(jié)構(gòu)上只包含通知狀態(tài)、事件類型和節(jié)點(diǎn)路徑，并不會(huì)告訴數(shù)據(jù)節(jié)點(diǎn)變化前后的具體內(nèi)容； |
| 時(shí)效性 | Watcher只有在當(dāng)前session徹底失效時(shí)才會(huì)無(wú)效，若在session有效期內(nèi)快速重連成功，則watcher依然存在，仍可接收到通知； |

Watcher事件類型(EventType)

EventType是數(shù)據(jù)節(jié)點(diǎn)(znode)發(fā)生變化時(shí)對(duì)應(yīng)的通知類型。EventType變化時(shí)KeeperState永遠(yuǎn)處于SyncConnected通知狀態(tài)下；當(dāng)KeeperState發(fā)生變化時(shí)，EventType永遠(yuǎn)為None。其路徑為org.apache.zookeeper.Watcher.Event.EventType，是一個(gè)枚舉類，枚舉屬性如下；

| 枚舉屬性 | 說(shuō)明 |
| None (-1) | 無(wú) |
| NodeCreated (1) | Watcher監(jiān)聽(tīng)的數(shù)據(jù)節(jié)點(diǎn)被創(chuàng)建時(shí) |
| NodeDeleted (2) | Watcher監(jiān)聽(tīng)的數(shù)據(jù)節(jié)點(diǎn)被刪除時(shí) |
| NodeDataChanged (3) | Watcher監(jiān)聽(tīng)的數(shù)據(jù)節(jié)點(diǎn)內(nèi)容發(fā)生變更時(shí)(無(wú)論內(nèi)容數(shù)據(jù)是否變化) |
| NodeChildrenChanged (4) | Watcher監(jiān)聽(tīng)的數(shù)據(jù)節(jié)點(diǎn)的子節(jié)點(diǎn)列表發(fā)生變更時(shí) |

Watcher通知狀態(tài)(KeeperState)

KeeperState是客戶端與服務(wù)端連接狀態(tài)發(fā)生變化時(shí)對(duì)應(yīng)的通知類型。路徑為org.apache.zookeeper.Watcher.Event.KeeperState，是一個(gè)枚舉類，其枚舉屬性如下；

| 枚舉屬性 | 說(shuō)明 |
| Unknown(-1) | 屬性過(guò)期 |
| Disconnected(0) | 客戶端與服務(wù)器斷開連接時(shí) |
| NoSyncConnected(1) | 屬性過(guò)期 |
| SyncConnected(3) | 客戶端與服務(wù)器正常連接時(shí) |
| AuthFailed(4) | 身份認(rèn)證失敗時(shí) |
| ConnectedReadOnly(5) | 3.3.0版本后支持只讀模式，一般情況下ZK集群中半數(shù)以上服務(wù)器正常，zk集群才能正常對(duì)外提供服務(wù)。該屬性的意義在于：若客戶端設(shè)置了允許只讀模式，則當(dāng)zk集群中只有少于半數(shù)的服務(wù)器正常時(shí)，會(huì)返回這個(gè)狀態(tài)給客戶端，此時(shí)客戶端只能處理讀請(qǐng)求 |
| SaslAuthenticated(6) | 服務(wù)器采用SASL做校驗(yàn)時(shí) |
| Expired(-112) | 會(huì)話session失效時(shí) |

image

ZAB協(xié)議

ZAB協(xié)議包括兩種基本的模式，分別是崩潰恢復(fù)和消息廣播。當(dāng)整個(gè)服務(wù)框架在啟動(dòng)過(guò)程中，或者是當(dāng)Leader服務(wù)器出現(xiàn)網(wǎng)絡(luò)中斷、崩潰退出與重啟等異常情況時(shí)，ZAB協(xié)議就會(huì)進(jìn)入恢復(fù)模式并選舉產(chǎn)生新的Leader服務(wù)器。當(dāng)選舉產(chǎn)生了新的Leader服務(wù)器，同時(shí)集群中已經(jīng)有過(guò)半的機(jī)器與該Leader服務(wù)器完成了狀態(tài)同步之后，ZAB協(xié)議就會(huì)退出恢復(fù)模式。其中，所謂的狀態(tài)同步是指數(shù)據(jù)同步，用來(lái)保證集群中存在過(guò)半的機(jī)器能夠和Leader服務(wù)器的數(shù)據(jù)狀態(tài)保持一致。

當(dāng)集群中已經(jīng)有過(guò)半的Follower服務(wù)器完成了和Leader服務(wù)器的狀態(tài)同步，那么整個(gè)服務(wù)框架就可以進(jìn)入消息廣播了。當(dāng)一臺(tái)同樣遵守ZAB協(xié)議的服務(wù)器啟動(dòng)后加入到集群中時(shí)，如果此時(shí)集群中已經(jīng)存在一個(gè)Leader服務(wù)器在負(fù)責(zé)進(jìn)行消息廣播，那么新加入的服務(wù)器就會(huì)自覺(jué)的進(jìn)入數(shù)據(jù)恢復(fù)模式： 找到Leader所在的服務(wù)器，與其進(jìn)行數(shù)據(jù)同步，然后一起參與到消息廣播流程中去。正如上文介紹中所說(shuō)的，Zookeeper設(shè)計(jì)成只允許唯一的一個(gè)Leader服務(wù)器來(lái)進(jìn)行事務(wù)請(qǐng)求的處理。Leader服務(wù)器在接收到客戶端的事務(wù)請(qǐng)求后，會(huì)生成對(duì)應(yīng)的事務(wù)提案并發(fā)起一輪廣播協(xié)議； 而如果集群中的其他機(jī)器接收到客戶端的事務(wù)請(qǐng)求，那么這些非Leader服務(wù)器會(huì)首先將這個(gè)事務(wù)請(qǐng)求轉(zhuǎn)發(fā)給Leader服務(wù)器。

當(dāng)Leader服務(wù)器出現(xiàn)崩潰退出或者機(jī)器重啟，亦或是集群中已經(jīng)不存在過(guò)半的服務(wù)器與該Leader服務(wù)器保持正常通行時(shí)，那么在重新開始新一輪原子廣播事務(wù)操作之前，所有進(jìn)程首先會(huì)使用崩潰恢復(fù)協(xié)議來(lái)使彼此達(dá)到一個(gè)一致的狀態(tài)，于是整個(gè)ZAB流程就會(huì)從消息廣播模式進(jìn)入到崩潰恢復(fù)模式。

一個(gè)機(jī)器要成為新的Leader，必須獲得過(guò)半進(jìn)程的支持，同時(shí)由于每個(gè)進(jìn)程都有可能會(huì)崩潰，因此，ZAB協(xié)議運(yùn)行過(guò)程中，前后會(huì)出現(xiàn)多個(gè)Leader，并且每個(gè)進(jìn)程也有可能會(huì)多次成為L(zhǎng)eader。進(jìn)入崩潰恢復(fù)模式后，只要集群中存在過(guò)半的服務(wù)器能夠彼此進(jìn)行正常通信，那么就可以產(chǎn)生一個(gè)新的Leader并再次進(jìn)入消息廣播模式。舉個(gè)例子來(lái)說(shuō)，一個(gè)由3臺(tái)機(jī)器組成的ZAB服務(wù)，通常由1個(gè)Leader，2個(gè)Follower服務(wù)器組成。某一個(gè)時(shí)刻，假如其中一個(gè)Follower服務(wù)器掛了，整個(gè)ZAB集群是不會(huì)中斷服務(wù)的，這是因?yàn)長(zhǎng)eader服務(wù)器依然能夠獲得過(guò)半機(jī)器（包括Leader自己）的支持。

消息廣播（5min）

類似于2PC

2pc 3pc

https://zh.wikipedia.org/wiki/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4

https://zh.wikipedia.org/wiki/%E4%B8%89%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4

3pc主要解決了2pc的單點(diǎn)故障，并引入超時(shí)機(jī)制

image

ZAB協(xié)議與二階段提交協(xié)議不同的是，ZAB協(xié)議在二階段提交過(guò)程中，移除了中斷邏輯。

ZAB協(xié)議在有過(guò)半的Follower服務(wù)器已經(jīng)反饋Ack之后就開始提交Proposal了，而不需要等待集群中所有Follower服務(wù)器都反饋?lái)憫?yīng)。

關(guān)于ZAB在Leader出現(xiàn)單點(diǎn)宕機(jī)如何保證事務(wù)提交，保證數(shù)據(jù)一致性，則引入崩潰恢復(fù)模式來(lái)解決這個(gè)問(wèn)題。

ZAB的消息廣播協(xié)議是基于具有FIFO（先進(jìn)先出）特性的TCP協(xié)議來(lái)進(jìn)行網(wǎng)絡(luò)通信，保證消息廣播過(guò)程中消息的接收與發(fā)送的順序性。

在整個(gè)消息廣播過(guò)程中，Leader服務(wù)器會(huì)為每一個(gè)事務(wù)請(qǐng)求的處理步驟：

(1)Leader服務(wù)器會(huì)為事務(wù)請(qǐng)求生成一個(gè)全局的的遞增事務(wù)ID（即ZXID），保證每個(gè)消息的因果關(guān)系的順序。

(2)Leader服務(wù)器會(huì)為該事務(wù)生成對(duì)應(yīng)的Proposal，進(jìn)行廣播。

(3)Leader服務(wù)器會(huì)為每一個(gè)Follower服務(wù)器都各自分配一個(gè)單獨(dú)的隊(duì)列，然后將需要廣播的事務(wù)Proposal依次放入這些隊(duì)列中去，并根據(jù)FIFO策略進(jìn)行消息發(fā)送。

(4)每一個(gè)Follower服務(wù)器在接收到這個(gè)事務(wù)Proposal之后，首先以日志形式寫入本地磁盤，并且成功寫入后反饋給Leader服務(wù)器一個(gè)Ack響應(yīng)

(5)當(dāng)Leader服務(wù)器接收超過(guò)半數(shù)的Follower的Ack響應(yīng)，Leader自身也會(huì)完成對(duì)事務(wù)的提交。同時(shí)就會(huì)廣播一個(gè)Commit消息給所有的Follower服務(wù)器以通知進(jìn)行事務(wù)提交。每一個(gè)Follower服務(wù)器在接收到Commit消息后，也會(huì)完成對(duì)事務(wù)的提交。

Zk的寫機(jī)制

所有的寫的請(qǐng)求，轉(zhuǎn)發(fā)給Leader，Leader采取兩階段提交的方式。

1. 本地生成自增的zxid，生成Proposal日志（持久化)

2. 廣播所有的Follower，并且有單獨(dú)的線程統(tǒng)計(jì) Ack Proposal的數(shù)量

3. Proposal ack過(guò)半之后，廣播Commit，并且把這個(gè)request丟到各自的CommitProcessor里面處理

4. Master commit日志，更新lastCommitZxid，apply到內(nèi)存樹中，Ack client操作成功

崩潰恢復(fù)

選主機(jī)制（發(fā)現(xiàn)）：

1）Zab 協(xié)議需要確保那些**已經(jīng)在 Leader 服務(wù)器上提交（****Commit****）的事務(wù)最終被所有的服務(wù)器提交**。

2）Zab 協(xié)議需要確保**丟棄那些只在 Leader 上被提出而沒(méi)有被提交的事務(wù)**。

image

保證P2最終被commit

image

保證P3被丟棄

sid, zxid

zxid 64位= epoch（周期） + 事務(wù)id（周期內(nèi)事務(wù)id）

在 Zab 的事務(wù)編號(hào) zxid 設(shè)計(jì)中，zxid是一個(gè)64位的數(shù)字。

其中低32位可以看成一個(gè)簡(jiǎn)單的單增計(jì)數(shù)器，針對(duì)客戶端每一個(gè)事務(wù)請(qǐng)求，Leader 在產(chǎn)生新的 Proposal 事務(wù)時(shí)，都會(huì)對(duì)該計(jì)數(shù)器加1。而高32位則代表了 Leader 周期的 epoch 編號(hào)。

epoch 編號(hào)可以理解為當(dāng)前集群所處的年代，或者周期。每次Leader變更之后都會(huì)在 epoch 的基礎(chǔ)上加1，這樣舊的 Leader 崩潰恢復(fù)之后，其他Follower 也不會(huì)聽(tīng)它的了，因?yàn)?Follower 只服從epoch最高的 Leader 命令。

每當(dāng)選舉產(chǎn)生一個(gè)新的 Leader ，就會(huì)從這個(gè) Leader 服務(wù)器上取出本地事務(wù)日志中最大編號(hào) Proposal 的 zxid，并從 zxid 中解析得到對(duì)應(yīng)的 epoch 編號(hào)，然后再對(duì)其加1，之后該編號(hào)就作為新的 epoch 值，并將低32位數(shù)字歸零，由0開始重新生成zxid。

zxid大的優(yōu)先，zxid相等用sid比較，這樣保證偏序關(guān)系，保證收斂

image

只有超過(guò)半數(shù)節(jié)點(diǎn)Ack了的事務(wù)操作，才會(huì)被commit，才會(huì)最終響應(yīng)到客戶端。所以響應(yīng)了客戶端的操作，不管leader是否掛了，新leader中肯定存了這個(gè)日志，否則選舉中不會(huì)獲勝。

未完成半數(shù)Ack的事務(wù)操作，leader掛了，新leader可能保存這個(gè)日志，也可能沒(méi)有保存這個(gè)日志。

通信協(xié)議：

jute（不是傳統(tǒng)的pb或者thrift）序列化

持久化以及數(shù)據(jù)同步：

背景：

數(shù)據(jù)存儲(chǔ)，備份，冗余，同步

分類：

FileTxnLog，事務(wù)日志

SnapLog，快照

作用：

應(yīng)用日志

diff同步，trunc+diff同步，trunc同步，snap同步

image

`diff同步`
`    peerLastZxid在min和max之間`
`trunc + diff`
`    leader處理事務(wù)記錄zxid后，發(fā)出proposal前掛掉了，也就是follower不知道這一條zxid`
`    follower無(wú)視這一條zxid進(jìn)行新的集群處理之后，老leader再進(jìn)來(lái)了，需要trunc + diff`
`trunc`
`    上述簡(jiǎn)單版，peerLastZxid>max`
`snap`
`沒(méi)辦法diff或者trunc，比如  peerLastZxid < min` 

實(shí)際應(yīng)用：

數(shù)據(jù)發(fā)布/訂閱 , 分布式鎖，分布式隊(duì)列等等
Kafka，solr，Eureka，Dubbo，hadoop，hbase
如何簡(jiǎn)單用zk弄一個(gè)服務(wù)發(fā)現(xiàn)

Future topic：

ACL
session管理
異常處理
服務(wù)器啟動(dòng)
watcher管理

image

延伸思考：（6min）

如果自己設(shè)計(jì)一個(gè)分布式系統(tǒng)，需要注意什么

CAP，2PC，3PC，分布式事務(wù)
選主機(jī)制，事務(wù)機(jī)制，執(zhí)行順序
通信協(xié)議，消息體定義，消息體格式(req，resp)，向前兼容
網(wǎng)絡(luò)IO，NIO，零拷貝，直接內(nèi)存，網(wǎng)絡(luò)流量負(fù)載，會(huì)話管理
序列化，反序列化機(jī)制
持久化日志，日志格式，日志索引，日志截?cái)?，日志清理，日志可視化，checksum，刷盤
數(shù)據(jù)崩潰恢復(fù)，增量同步，鏡像同步
配置，服務(wù)端conf和client conf，心跳，超時(shí)等參數(shù)
狀態(tài)機(jī)，狀態(tài)處理，回調(diào)
負(fù)載均衡，監(jiān)控
伸縮性，動(dòng)態(tài)擴(kuò)縮容，單機(jī)內(nèi)存，硬盤大小，支持qps
邊界情況，異常處理，機(jī)器掛了，網(wǎng)絡(luò)不通，腦裂

可以結(jié)合netty，redis，mysql，kafka橫向?qū)Ρ?/p>

kafka: HW，ISR，OSR，心跳
Redis: gossip，aof，rdb，線程模型
Mysql: binlog，主從同步，數(shù)據(jù)冗余
netty: 零拷貝

重點(diǎn)總結(jié)：

zab的廣播和崩潰恢復(fù)

`為什么要有兩個(gè)狀態(tài)，廣播和崩潰恢復(fù)`
`崩潰恢復(fù)的時(shí)候如何選主 `
`    什么時(shí)候會(huì)處于崩潰狀態(tài)   `
`    sid+zxid,保證偏序關(guān)系，保證收斂`
`        為什么要zxid，為什么要sid，為什么要收斂`
`    zxid 64位由什么組成，epoch代表什么，事務(wù)id代表什么`
`    為什么要過(guò)半同意，過(guò)半為什么是>而不是>=一半`
`    如何利用日志來(lái)恢復(fù)數(shù)據(jù)`
`        diff+trunc+snap`
`        為什么優(yōu)先用diff，用不了diff就用snap`
`        為什么不能保存全量日志`
`如何消息廣播`
`    為什么要類似2pc，一階段會(huì)有什么問(wèn)題`
`    為什么要記錄日志，為什么要兩種日志，為什么zk單節(jié)點(diǎn)大小不建議超過(guò)1M`
`    數(shù)據(jù)如何冗余`
`    zk是強(qiáng)一致的么，是哪種一致`
`    事務(wù)的順序如何保證的`
`        zk的寫操作全部給leader保證`

再回顧最上面的簡(jiǎn)介

思考題

`leader掛了之后再恢復(fù)，它還能成為leader么`
`zk會(huì)腦裂么，腦裂還會(huì)提供服務(wù)么，為什么要奇數(shù)臺(tái)`
`如果leader發(fā)出提議之后還沒(méi)有過(guò)半機(jī)器ack就掛了，那么下次這個(gè)提議是否被新leader應(yīng)用`
`    不保證，比如abcde中a是leader，b收到了，cde沒(méi)收到`
`    如果b沒(méi)掛，bcde網(wǎng)絡(luò)正常，那么新的b是leader，能應(yīng)用這個(gè)提議`
`    如果b也掛了或者b和cde網(wǎng)絡(luò)不通，那么新leader的cde中選一個(gè)，就不會(huì)應(yīng)用這個(gè)提議，b恢復(fù)了之后也會(huì)要trunc+diff或者snap`
`zk為什么快`
`一個(gè)之前掛掉的機(jī)器加入一個(gè)正常狀態(tài)的集群需要做什么，能直接向client提供服務(wù)嗎`

refer：

http://zookeeper.apache.org/doc/current/zookeeperOver.html zk官網(wǎng)

https://juejin.im/post/5b037d5c518825426e024473 zk漫畫簡(jiǎn)介

https://blog.csdn.net/weixin_44778202/article/details/90315015 zk思維導(dǎo)圖

《paxos到zk》 核心第四章 第七章

http://www.itdecent.cn/p/dc292f72089a 讀寫機(jī)制

https://www.cnblogs.com/sunddenly/p/4138580.html zk一致性原理

http://www.kailing.pub/raft/index.html raft算法達(dá)成一致