1. Zookeeper是個(gè)啥

ZooKeeper 是為分布式系統(tǒng)中各個(gè)服務(wù)主機(jī)提供高可用、高性能、具備嚴(yán)格順序訪問控制的協(xié)調(diào)服務(wù),

• 提供一個(gè)多層級(jí)的節(jié)點(diǎn)命名空間znode,采用watch機(jī)制監(jiān)聽znode，當(dāng)znode節(jié)點(diǎn)數(shù)據(jù)變更時(shí)通知
  client做出對(duì)應(yīng)業(yè)務(wù)上的變更
• 節(jié)點(diǎn)屬性zxid的遞增，保證了事務(wù)順序的一致性，

2. znode的類型

• PERSISTENT 持久化節(jié)點(diǎn)
• PERSISTENT_SEQUENTIAL 持久化有序節(jié)點(diǎn)
• EPHEMERAL 臨時(shí)節(jié)點(diǎn),臨時(shí)節(jié)點(diǎn)斷開會(huì)刪除
• EPHEMERAL_SEQUENTIAL 臨時(shí)有序節(jié)點(diǎn)

String ss = "123";
int a = 1

3. zk可以用來做什么

• 負(fù)載均衡，客戶端從zk獲取服務(wù)信息時(shí)，按照負(fù)載策略返回地址
• master選舉(recipes下有demo),通過ZAB協(xié)議利用節(jié)點(diǎn)信息投票,選取leader節(jié)點(diǎn)
• 集群管理，臨時(shí)有序節(jié)點(diǎn)存儲(chǔ)broker信息,通過心跳檢測(cè),當(dāng)斷開連接臨時(shí)節(jié)點(diǎn)刪除，新的服務(wù)
  啟動(dòng)，注冊(cè)到指定臨時(shí)節(jié)點(diǎn)中
• 分布式鎖(recipes下有demo)

• 利用節(jié)點(diǎn)不可重復(fù)創(chuàng)建來實(shí)現(xiàn)鎖，創(chuàng)建成功獲取鎖，失敗retry，直到獲取到鎖
• 高性能的分布式鎖采用一個(gè)有序節(jié)點(diǎn)來做一個(gè)鎖隊(duì)列,進(jìn)行鎖分配，頭節(jié)點(diǎn)(即序號(hào)最小)為自己時(shí)獲取鎖成功，具體同AQS原理

• 配置管理，利用節(jié)點(diǎn)存儲(chǔ)配置信息，watch節(jié)點(diǎn)進(jìn)行配置變更處理
• 分布式隊(duì)列(recipes下有demo)，持久化有序節(jié)點(diǎn)按序消費(fèi)
• 數(shù)據(jù)發(fā)布和訂閱，對(duì)節(jié)點(diǎn)進(jìn)行watch
• 命名服務(wù)，利用節(jié)點(diǎn)存儲(chǔ)服務(wù)信息 通過指定的名字來獲取資源或者服務(wù)的地址

4. zk的數(shù)據(jù)復(fù)制

復(fù)制能提高容錯(cuò)性、系統(tǒng)擴(kuò)展能力、性能

• 容錯(cuò):一個(gè)節(jié)點(diǎn)出錯(cuò)，不致于讓整個(gè)系統(tǒng)停止工作，別的節(jié)點(diǎn)可以接管它的工作;
• 提高系統(tǒng)的擴(kuò)展能力 :把負(fù)載分布到多個(gè)節(jié)點(diǎn)上，或者增加節(jié)點(diǎn)來提高系統(tǒng)的負(fù)載能力;
• 提高性能:讓客戶端本地訪問就近的節(jié)點(diǎn)，提高用戶訪問速度

可以采用寫主和寫任意模式，zk采用基于ZAB理論實(shí)現(xiàn)數(shù)據(jù)復(fù)制和master選舉

• 寫主(WriteMaster) 方式，對(duì)數(shù)據(jù)的修改提交給指定的節(jié)點(diǎn)。
• 寫任意(Write Any)方式對(duì)數(shù)據(jù)的修改可提交給任意的節(jié)點(diǎn)

5. zk的工作原理

zk通過zab協(xié)議來保證server之間的同步，zab協(xié)議分為恢復(fù)模式和廣播模式

• 恢復(fù)模式是master服務(wù)掛了后進(jìn)行master選舉
• 廣播模式是數(shù)據(jù)的同步

6. zk下server工作狀態(tài)

每個(gè) Server 在工作過程中有三種狀態(tài):

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

7. zk 如何選取leader

當(dāng) leader 崩潰或者 leader 失去大多數(shù)的 follower，這時(shí) zk 進(jìn)入恢復(fù)模式,

• 基于 basic paxos算法,

• 發(fā)起詢問zxid，收到返回計(jì)算出最大zxid
• 與最大zxid一致的server參與選舉，當(dāng)某個(gè)server得到票數(shù)超過一半，則選舉為leader，否則繼續(xù)

• 基于 fast paxos算法,

• 發(fā)起選舉提議，其他服務(wù)解決 epoch 和 zxid 的沖突，并接受對(duì)方的提議，當(dāng)超過半數(shù)的server
  返回接收提議則選舉成功，否則繼續(xù)下一輪

8. zk同步流程

選完 Leader 以后，zk 就進(jìn)入狀態(tài)同步過程。

• Leader 等待 server 連接;
• Follower 連接 leader，將最大的 zxid 發(fā)送給 leader;
• Leader 根據(jù) follower 的 zxid 確定同步點(diǎn);
• 完成同步后通知 follower 已經(jīng)成為 uptodate 狀態(tài);
• Follower 收到 uptodate 消息后，又可以重新接受 client 的請(qǐng)求進(jìn)行服務(wù)了。

9. 為什么要有l(wèi)eader

其他server可以共享結(jié)果，減少重復(fù)計(jì)算，提高性能

10. zk節(jié)點(diǎn)宕機(jī)如何處理

如果是leader宕機(jī)，則進(jìn)行選舉leader，follower集群繼續(xù)使用，當(dāng)超過半數(shù)宕機(jī)，
則將停止服務(wù)，所以follower宕機(jī)咋辦，趕緊檢查宕機(jī)原因，起來服務(wù)

11. zk和Nginx的負(fù)載區(qū)別

zk 的負(fù)載均衡是可以調(diào)控，
nginx 只是能調(diào)權(quán)重，其他需要可控的都需要自己寫插件;但是 nginx 的吞吐量比 zk 大很多，應(yīng)該說按業(yè)務(wù)選擇用哪種方式}{

12. zk的wath機(jī)制

• zk的watch是一次性的，只會(huì)出發(fā)一次
• Zookeeper 只能保證最終的一致性， 而無法保證強(qiáng)一致性
• 通過getData、exists、getChildren注冊(cè)watch
• create、delete、setData 可出發(fā)watch
• 服務(wù)連接可以watch，bu丟失連接沒法watch，so需要心跳檢測(cè)，就會(huì)存在弱一致性

13. 2PC、3PC

都存在 單點(diǎn)問題、同步阻塞、數(shù)據(jù)不一致、容錯(cuò)不好

2PC(two-phase-commit兩階段提交)簡單容易實(shí)現(xiàn)

• 第一階段 prepare 雙方進(jìn)行確認(rèn)，會(huì)進(jìn)行加鎖
• 第二階段 commit 雙方進(jìn)行確認(rèn)提交

3PC(相比較減少了單點(diǎn)故障，效率也更高)

• cancommit，不鎖表，避免等待響應(yīng)時(shí)鎖表阻塞
• precommit，鎖表
• docommit，

14. CAP、BASE、ZAB

CAP理論(三者不可同時(shí)兼得,需要做的是保證分區(qū)容錯(cuò)性的前提下,均衡一致性與可用性)

• 一致性(強(qiáng)一致性、弱一致性)---需要考慮保證 最終一致性
• 可用性(一直處于可用)---需要考慮保證基本可用,降級(jí)處理
• 分區(qū)容錯(cuò)性(不出現(xiàn)網(wǎng)絡(luò)分區(qū)現(xiàn)象)

BASE理論

• Basically available 基本可用
• soft state 軟狀態(tài),即三態(tài)的中間態(tài),數(shù)據(jù)同步過程存在延遲，不影響系統(tǒng)可用性(消息隊(duì)列排隊(duì))
• eventually consistent 最終一致性,數(shù)據(jù)經(jīng)過一定時(shí)間同步，能夠達(dá)到最終一致的狀態(tài)