Zab系列博客
Raft Vs Zab
http://www.itdecent.cn/p/24307e7ca9da
Zab系列1 核心概念
http://www.itdecent.cn/p/76e5dba31ea4
Zab系列2 角色和存儲(chǔ)
http://www.itdecent.cn/p/d80f9250ffd1
Zab系列3 選舉
http://www.itdecent.cn/p/0d2390c242f6
Zab系列4 zookeeper特性
http://www.itdecent.cn/p/08b62ca1fe4e
Zab系列5 選舉恢復(fù)（源碼分析）
http://www.itdecent.cn/p/b6acd99921b7
Zab系列6 zk單機(jī)版工作原理
http://www.itdecent.cn/p/ed45982b18b4
Zab系列7 集群工作原理Leader篇
http://www.itdecent.cn/p/59240c36ba1b
Zab系列8 集群工作原理Follower篇
http://www.itdecent.cn/p/8d7c7f1b2838
Zab系列9 消息順序性
http://www.itdecent.cn/p/0aa96b6a2070
區(qū)別
- 請(qǐng)求的處理方式不同
Zk集群中的client和任意一個(gè)Node建立TCP的長(zhǎng)連接，完成所有的交互動(dòng)作，而Raft第一次隨機(jī)的獲取到一個(gè)節(jié)點(diǎn)，然后找到Leader后，后續(xù)直接和leader交互
Zk中的讀請(qǐng)求，直接由連接的Node處理，不需要和leader匯報(bào)，也就是Consul中的stale模式。這種模式可能導(dǎo)致讀取到的數(shù)據(jù)是過(guò)時(shí)的，但是可以保證一定是半數(shù)節(jié)點(diǎn)之前確認(rèn)過(guò)的數(shù)據(jù)
為了避免Follower的數(shù)據(jù)過(guò)時(shí)，Zk有sync()方法，可以保證讀取到最新的數(shù)據(jù)?？梢哉{(diào)用sync()之后，再查詢，確保所有的數(shù)據(jù)一致后再返回結(jié)果
角色Zk引入了 Observer的角色來(lái)提升性能，既可以大幅提升讀取的性能，也可以不影響寫的速度和選舉的速度，同時(shí)一定程度上增加了容錯(cuò)的能力。
https://www.cnblogs.com/EasonJim/p/7488484.html日志和狀態(tài)機(jī)
Zab和Raft都是同時(shí)存在 log[]（還有快照技術(shù)）和狀態(tài)機(jī)（內(nèi)存樹(shù)）的存儲(chǔ)結(jié)構(gòu)。
- 日志是以log和快照的形式持久化到磁盤，保存的是數(shù)據(jù)寫的完整過(guò)程，為重啟加載歷史數(shù)據(jù)提供了便利，避免了服務(wù)器宕機(jī)造成的數(shù)據(jù)丟失。
- 狀態(tài)機(jī)（內(nèi)存樹(shù)）把數(shù)據(jù)加載到內(nèi)存中，避免了查詢操作時(shí)磁盤讀取，讀取的是數(shù)據(jù)的最終值，從而提升讀取的性能
Zab中的日志和Raft中的日志模型很像，都是超過(guò)半數(shù)節(jié)點(diǎn)完成復(fù)制之后，該命令才會(huì)被commit，而結(jié)合半數(shù)節(jié)點(diǎn)confrim之后的節(jié)點(diǎn)才有可能成為新leader，這兩點(diǎn)保證了集群的一致性。
選主投票的區(qū)別：
Zk集群之間投票消息是單向、網(wǎng)狀的，類似于廣播，比如A廣播A投票給自己，廣播出去，然后B接收到A的這個(gè)消息之后，會(huì)PK A的數(shù)據(jù)，如果B更適合當(dāng)leader（數(shù)據(jù)更新或者myid更大），B會(huì)歸檔A的這個(gè)投票，但是不會(huì)更新自己的數(shù)據(jù)，也不會(huì)廣播任何消息。除非發(fā)現(xiàn)A的數(shù)據(jù)比B當(dāng)前存儲(chǔ)的數(shù)據(jù)更適合當(dāng)leader，就更新自己的數(shù)據(jù)，且廣播自己的最新的投票消息。
而Raft集群之間的所有消息都是雙向的，發(fā)起一個(gè)RPC，會(huì)有個(gè)回復(fù)結(jié)果。比如A向B發(fā)起投票，B要么反饋投票成功，要么反饋投票不成功。ZK集群中，一個(gè)節(jié)點(diǎn)在一個(gè)epoch下是可以發(fā)起多次投票的，當(dāng)節(jié)點(diǎn)發(fā)現(xiàn)有比之前更新的數(shù)據(jù)更適合的leader時(shí)，就會(huì)廣播自己的最新投票消息，結(jié)合recvset這個(gè)Set的結(jié)構(gòu)，來(lái)更新某個(gè)結(jié)點(diǎn)最新的投票結(jié)果。而Raft的follower在一個(gè)term里只能投票一次。
ZK集群中，因?yàn)橐肓薽yid的概念，系統(tǒng)傾向讓數(shù)據(jù)最新和myid最大的節(jié)點(diǎn)當(dāng)leader，所以即使有半數(shù)節(jié)點(diǎn)都投票給同一個(gè)Node當(dāng)leader，這個(gè)Node也不一定能成為leader，需要等待200ms，看是不是有更適合的leader產(chǎn)生，當(dāng)然如果可能因?yàn)榫W(wǎng)絡(luò)原因 數(shù)據(jù)最新 myid最大的節(jié)點(diǎn)也不一定能當(dāng)選為leader。但是在Raft系統(tǒng)中，只要某個(gè)candidate發(fā)現(xiàn)自己投票過(guò)半了，就一定能成為leader
ZK集群中，每一輪的選舉一定會(huì)選出一個(gè)leader，因?yàn)槊總€(gè)節(jié)點(diǎn)允許多次投票，而且會(huì)廣播自己的最新投票結(jié)果。而Raft系統(tǒng)可能涉及選票瓜分，需要重新發(fā)起一輪選舉才能選出leader，是通過(guò)選舉超時(shí)時(shí)間的隨機(jī)來(lái)降低選票瓜分的概率。所以ZK的選舉理論上一般需要花費(fèi)更多的時(shí)間，但是只需要一輪。Raft每一輪選舉的時(shí)間是大致固定的，但是不一定一輪就能選出leader。
ZK集群中，成為公認(rèn)的leader條件更苛刻，raft模式下，只要新leader發(fā)一個(gè)命令為空的Log出來(lái)，大家就會(huì)認(rèn)同這個(gè)節(jié)點(diǎn)為leader，但是在ZK集群中，追隨leader的2種條件都很苛刻
- 要么recvset中半數(shù)節(jié)點(diǎn)的選舉following投票給A，才會(huì)認(rèn)可A為自己的leader
- 要么outofelection中半數(shù)節(jié)點(diǎn)都認(rèn)可A為leader，自己才會(huì)認(rèn)可A為自己的leader
事務(wù)操作的區(qū)別
Raft系統(tǒng)中的事務(wù)消息是通過(guò)雙向的RPC來(lái)完成的，而Zab中，則是單向的，一來(lái)一回兩個(gè)消息來(lái)完成的。明顯Zab的性能更加，不需要浪費(fèi)leader一個(gè)線程去等待follower完成業(yè)務(wù)操作。
Zab中l(wèi)eader發(fā)送一個(gè)Proposal消息給follower，發(fā)送完成。當(dāng)follower完成proposal過(guò)程時(shí)，再發(fā)送一個(gè)消息ACK到leader，發(fā)送完成。leader統(tǒng)計(jì)ACK數(shù)量過(guò)半時(shí)，觸發(fā)廣播commit。操作流程當(dāng)中，Zab的即時(shí)性做的更好吧。
Raft的集群模式下：
Leader創(chuàng)建日志，廣播日志，半數(shù)節(jié)點(diǎn)復(fù)制成功后，自己commit日志，運(yùn)用到狀態(tài)機(jī)中，反饋客戶端，并且在下一個(gè)心跳包中，通知小弟們commit
Zab的集群模式下：
leader創(chuàng)建Proposal，廣播之后，半數(shù)節(jié)點(diǎn)復(fù)制成功后，廣播commit。同時(shí)自己也commit，commit完之后再運(yùn)用到內(nèi)存樹(shù)，反饋客戶端
