1煤率、zab協(xié)議
分布式一致性協(xié)議包括proxy，但是 ZooKeeper并沒有完全采用Paxos算法漏策，而是使用了一種稱為ZooKeeper Atomic Broadcast(ZAB,zookeeper原子消息廣播協(xié)議)的協(xié)議作為其數(shù)據(jù)一致性的核心算法宅粥。
ZAB協(xié)議是為分布式協(xié)調(diào)服務(wù)ZooKeeper專門設(shè)計的一種支持漰潰恢復(fù)的原子廣播協(xié)議闽寡。
所有事務(wù)請求必須由一個全局唯一的服務(wù)器來協(xié)調(diào)處理帮碰，這樣的服務(wù)器稱為Leader服務(wù)器相味，而余下的其他服務(wù)器則成為Follower服務(wù)器。Leader服務(wù)器負(fù)責(zé)將一個客戶端事務(wù)請求轉(zhuǎn)換成一個事務(wù)Proposal(提議)殉挽，并將該Proposal分發(fā)給集群中所有的Follower服務(wù)器丰涉。之后Leader服務(wù)器需要等待所有Follower服務(wù)器的反饋，一旦超過半數(shù)的Follower服務(wù)器進(jìn)行了正確反饋后斯碌，那么Leader就會再次向所有的Follower服務(wù)器分發(fā)Commit消息昔搂，要求其將前一個Proposal進(jìn)行提交。
1输拇、簡述ZAB協(xié)議
zab協(xié)議是一種支持崩潰恢復(fù)的原子廣播協(xié)議，他能夠保證集群中各個副本數(shù)據(jù)的一致贤斜，支持全局唯一的變更序列策吠，支持崩潰恢復(fù)。
2瘩绒、zab如何做個各個副本數(shù)據(jù)的一致猴抹？
在zab中只有l(wèi)eader可以處理事務(wù)請求，把數(shù)據(jù)變更的操作以事務(wù)proposal的形式廣播給集群中所有的節(jié)點锁荔，然后等待反饋蟀给，如果超過半數(shù)節(jié)點都通過，再次發(fā)送commit請求完成數(shù)據(jù)變更阳堕。
3跋理、zab如何保證數(shù)據(jù)變更的全局順序？
通過zxid來保證恬总，zxid是一個64位的數(shù)字前普，前32位是一個epoch編號，每次領(lǐng)導(dǎo)選舉之后就會加1壹堰，后32位是一個自增的序列拭卿，每個事務(wù)請求自動加1骡湖，并且leader會為所有的follwer維護(hù)一個發(fā)送隊列，將發(fā)送的proposal按照先后順序存入隊列中依次發(fā)送峻厚。
4响蕴、zab如何支持崩潰恢復(fù)？
集群中所有的服務(wù)器都以長連接的形式保持通信惠桃，如果集群中超過一半以上的follwer無法連接到leader浦夷，就會自動進(jìn)入領(lǐng)導(dǎo)選舉，進(jìn)而選舉出新的leader
5刽射、zab的工作模式簡介
zab有兩種工作模式军拟，一種是恢復(fù)模式，一種是廣播模式誓禁⌒赶ⅲ恢復(fù)模式下進(jìn)行領(lǐng)導(dǎo)選舉，廣播模式處理事務(wù)請求摹恰。
6辫继、簡述領(lǐng)導(dǎo)選舉過程
首先服務(wù)器將自身狀態(tài)轉(zhuǎn)換為looking，并向集群中所有的服務(wù)器發(fā)起投票（myid,zxid）
接收其他服務(wù)器發(fā)送的投票俗慈，并進(jìn)行處理姑宽，按照zxid最大的作為leader，如果相同按照myid最大的作為leader闺阱，更新投票信息炮车，再次向集群發(fā)送投票
統(tǒng)計投票結(jié)果，超過半數(shù)以上的投票即為leader
如果leader是自己酣溃，就把自己的狀態(tài)變更為leading瘦穆，否則變?yōu)閒ollwing
7、簡述事務(wù)請求的過程
只有l(wèi)eader可以處理事務(wù)請求赊豌，follwer接收到事務(wù)請求后要轉(zhuǎn)發(fā)給leader
leader以proposal的形式發(fā)送給所有的follwer扛或，等待響應(yīng)
follwer接收到請求后首先記錄事務(wù)日志拼卵，然后返回響應(yīng)
如果超過半數(shù)以上的follwer都返回正確的響應(yīng)术浪，再次向所有follwer發(fā)送commit請求
follwer開始變更內(nèi)存數(shù)據(jù)庫
最后響應(yīng)客戶端
8潮罪、watcher機制簡介
客戶端使用watchmanager來存儲注冊節(jié)點和watcher對象的映射
客戶端向服務(wù)端發(fā)送注冊路徑和狀態(tài)信息熊杨，服務(wù)端會把路徑和當(dāng)前的連接servercnxn存儲在內(nèi)部的watchmanager中
一旦節(jié)點數(shù)據(jù)有變化就從watchmanager中查出servercnxn莺丑，并回調(diào)process
回調(diào)客戶端桃序，客戶端從watchmanager中取出watcher战惊，執(zhí)行回調(diào)邏輯
9信柿、zookeeper是如何保證原子更新的钠绍？
采用樂觀鎖秆吵，類似JDK中的cas操作，讀取數(shù)據(jù)五慈，校驗纳寂，提交主穗，使用version來校驗數(shù)據(jù)從讀取后有沒有發(fā)送變化
10、sessionId是如何生成的毙芜，如何保證其全局唯一忽媒？
sessionId是64位的數(shù)字，前8位是myid腋粥，后56位是當(dāng)前的時間戳
11晦雨、簡述zookeeper會話管理
zk使用會話管理器sessiontracker來管理session。sessiontracker使用分桶策略來管理session隘冲，客戶端創(chuàng)建或刷新session的時候會按超時時間來把session放到不同的桶里闹瞧。后臺有一個專門線程負(fù)責(zé)來在固定的時間點定時檢查session，如果session在超時時間范圍內(nèi)已經(jīng)刷新展辞，就會被重新放到新的桶里奥邮，如果沒有刷新就會被清理掉。
12罗珍、簡述zk的數(shù)據(jù)存儲
zk事務(wù)日志
zk dump洽腺，定期dump，可以配置日志記錄數(shù)量超過多少次之后就可以把內(nèi)存中的數(shù)據(jù)dump到快照文件中去覆旱。
