概述
zookeeper的內(nèi)存模型：
- zk的數(shù)據(jù)存在內(nèi)存當(dāng)中（高性能）蹦骑，但是同時(shí)記錄操作日志+內(nèi)存快照（二進(jìn)制），持久化控乾。（類似于Redis)
- 狀態(tài)機(jī)+命令日志：內(nèi)存中保存數(shù)據(jù)的最終狀態(tài)润绎，命令日志中保存所有的操作過(guò)程，內(nèi)存快照中保存某一時(shí)間節(jié)點(diǎn)的狀態(tài)機(jī)中的數(shù)據(jù)图甜。
zookeeper集群的高性能：
- 內(nèi)存讀取數(shù)據(jù)
- 所有Node直接response 讀請(qǐng)求，不需要走M(jìn)aster
- 集群有Obeserver角色鳖眼，擴(kuò)展了讀的性能黑毅，又不影響投票和寫的性能（不參與選舉投票和ack proposal)
Zk的寫機(jī)制
所有的寫的請(qǐng)求，轉(zhuǎn)發(fā)給Leader钦讳，Leader采取兩階段提交的方式矿瘦。
- 本地生成自增的zxid，生成Proposal日志（持久化)
- 廣播所有的Follower愿卒，并且有單獨(dú)的線程統(tǒng)計(jì) Ack Proposal的數(shù)量
- Proposal ack過(guò)半之后缚去，廣播Commit，并且把這個(gè)request丟到各自的CommitProcessor里面處理
- Master commit日志琼开，更新lastCommitZxid易结，apply到內(nèi)存樹中，Ack client操作成功
這里和Raft系統(tǒng)不同柜候，Raft是master先commit搞动，再ack 客戶，最后在下一個(gè)心跳消息里面通知所有小弟們commit
zk的讀機(jī)制
- Client直接和Zk的節(jié)點(diǎn)直連渣刷，如果是讀的請(qǐng)求鹦肿，那么Node可以直接response，不需要走M(jìn)aster辅柴，保障了基于內(nèi)存的快速讀取
- zk集群不能保證讀取到的數(shù)據(jù)是最新的狮惜，但是可以保證讀取到的數(shù)據(jù)高诺，都是過(guò)半節(jié)點(diǎn)ACK確認(rèn)的數(shù)據(jù)
- zk的讀取本來(lái)就沒(méi)有鎖的概念，一個(gè)消息還在寫碾篡，是讀取不到的，不像Hashtable筏餐。即使Master完成了寫的操作开泽，如果Follower沒(méi)有Sync數(shù)據(jù)的話，也是讀取不到最新的數(shù)據(jù)的
- Zk直接兩種模式：默認(rèn)模式（CP模式 選舉時(shí)停止讀寫請(qǐng)求）魁瞪、Readonlymode模式（AP模式 選舉時(shí)停止寫請(qǐng)求穆律，但是可以讀）
zk的角色
- LOOKING：進(jìn)入leader選舉狀態(tài)
- FOLLOWING：leader選舉結(jié)束，進(jìn)入follower狀態(tài)
- LEADING：leader選舉結(jié)束导俘，進(jìn)入leader狀態(tài)
- OBSERVING：處于觀察者狀態(tài)
Observers和follower非常類似峦耘，observer的優(yōu)點(diǎn)
- 可以靈活的擴(kuò)展zk集群，新增和減少observer不會(huì)觸發(fā)重新選舉
- 大幅提升讀取的速度的同時(shí)旅薄，不會(huì)降低寫的速度
- 一定程度上提升容災(zāi)率辅髓，因?yàn)镺bserver的宕機(jī)不會(huì)影響集群繼續(xù)服務(wù)
選舉過(guò)程
和Raft算法相比，有點(diǎn)過(guò)度設(shè)計(jì)了少梁，解決的是一個(gè)標(biāo)準(zhǔn)的拜占庭問(wèn)題洛口，不僅僅可以處理節(jié)點(diǎn)故障問(wèn)題，還可以防止節(jié)點(diǎn)作弊凯沪。代價(jià)是消息交互的次數(shù)大大增加第焰。
每個(gè)Node都在統(tǒng)計(jì)leader獲取的投票數(shù)，只有Node統(tǒng)計(jì)有新leader產(chǎn)生時(shí)妨马，才會(huì)從Looking狀態(tài)挺举，切換成Following狀態(tài)，而不是收到Leader的消息烘跺，就進(jìn)入Following狀態(tài)湘纵。
- Zk所有Node啟動(dòng)時(shí)都有一個(gè)獨(dú)立的線程，不停的check自己當(dāng)前的Role
- 啟動(dòng)剛啟動(dòng)時(shí)液荸、Follower 超時(shí)仍未收到心跳瞻佛、Leader不能收到過(guò)半心跳恢復(fù)時(shí)，節(jié)點(diǎn)都會(huì)進(jìn)入Looking狀態(tài)
- 每個(gè)節(jié)點(diǎn)可以多次投票娇钱，每次投票都會(huì)廣播出去伤柄，一輪投票必定有一個(gè)leader產(chǎn)生，數(shù)據(jù)最新的節(jié)點(diǎn)肯定會(huì)成為leader文搂，server id 越大适刀，成為leader的概率也越高。
zk 一致性保證
只有超過(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è)日志吼过。
- 如果新leader沒(méi)有這個(gè)事務(wù)操作的日志锐秦，依賴客戶端的超時(shí)重試機(jī)制，來(lái)完成這個(gè)proposal盗忱，客戶端會(huì)發(fā)起重試酱床。
- 如果新leader有這個(gè)uncommitted的事務(wù)操作日志，則會(huì)替代老leader繼續(xù)完成這個(gè)操作
zk 事務(wù)操作有序性
- zk只能保證寫操作的有序性趟佃，而不能保證讀寫的有序性扇谣，比如Client先發(fā)起一個(gè)寫操作，再迅速發(fā)起一個(gè)讀取操作揖闸，并不能保證讀取的最新的數(shù)據(jù)揍堕。
- zk通過(guò)自增的zxid的編號(hào)，在前期proposal和持久化的時(shí)候汤纸，并不需要嚴(yán)格有序衩茸，提升寫的性能，但是在commit的時(shí)候贮泞，通過(guò)鎖和有序FIFO隊(duì)列楞慈，保證嚴(yán)格的有序commit，apply到內(nèi)存樹中啃擦。
