zk的服務器模式
仲裁模式：zk複製集羣中所有服務器的數據；大多數服務器保存數據成功後才返回客戶端成功
獨立模式：一個單獨的服務器，zk的狀態無法複製
會話
1.客戶端設置的監視點和會話相關聯，會話到期後等待中的監視點會移除
2.在對zk集合進行任何操作之前，必須先與服務器創建會話
3.當會話因爲某種原因終止時，這個會話建立的臨時節點也會消失
4.zk客戶端可以透明的將會話從一個服務器轉移到另一個服務器
5.會話提供了順序保證，保證一個會話中的請求按FIFO的順序執行，但當一個客戶端打開了多個會話不能保證FIFO
zk的架構設計
節點角色
1.leader：
領導者負責投票的發起和決議，狀態的維護
2.learner：
follower：接受客戶端的請求，返回數據；參與投票；
observer：接受客戶端的讀請求，返回數據，如果是寫請求會轉發給leader；不影響提議，不參與投票；只同步leader的狀態（數據）
observer和follower的區別是observer不參與選舉和投票；數據不同不到磁盤，每次重啓後需要全量同步數據；引入observer的目的是在不犧牲寫的性能下，提高讀的性能
集羣中唯一的leader節點，唯一對外負責寫請求，集羣中的節點都可以接受讀請求,learner節點接收到寫請求後會轉發給leader
數據一致性zab協議
zk通過zab原子廣播協議來保證每個節點的數據一致性；
zk對數據一直性的特點
- 順序一致性：嚴格按照事物發起的順序執行操作
- 原子性：所有事物的請求結果在集羣中所有節點上的應用情況是一樣的
- 單一視圖：客戶端訪問任何一個節點獲取到的數據模型是一樣的
- 實時性：包含在極小的一段時間內，客戶端可以讀取到服務器最新的數據狀態，如果需要實時需要客戶端調用sync方法
寫的示例圖
1.leader節點接收到寫請求後會分配一個全局的事物ID（zxid），併發起提議，廣播給每個follower；
2.follower接收到事物 請求後，寫入到本地事物日誌，根據事物的執行結果，和zxid的有效性來返回是否接受這個提議；
3.leader接收到超過半數的節點（包括自己）的ack請求，則執行事物提交請求，自己執行提交併且廣播給follower和同步狀態給observer；
4.follower接受到事物提交請求後，進行事物的提交
leader選舉
選舉觸發的條件
當集羣初始化（崩潰恢復）或者follower沒辦法聯繫上leader時，每個follower會進入選舉模式
選舉的原則
誰的數據最新，誰就具有優先選舉爲leader的資格；
選舉的步驟
1.發起選票、每個節點都投自己 一票並提議別的節點也投自己一票
2.選票重投階段、根據第一階段的投票決定投哪一個節點
3.選票統計、哪個節點收到了超過半數的投票，則變更狀態爲leader節點其餘的節點變更爲learner；
選舉完後，會進行數據的同步，只有數據同步完成後這個節點纔會對外提供服務
####數據的持久化
服務器只有強制沖刷事務到事務日誌中，纔會確認對應的提議
數據的類型
- 內存數據庫：全部數據存儲在內存中默認爲1M
- 事務日誌：每次寫操作完成後保存到內存中的同時會寫入到事務日誌
- 快照日誌：當事務日誌的寫入次數超過一定數量後（默認10W），會將內存數據庫中的數據進行一次備份，存儲到磁盤上，這個文件是快照文件
快照文件是一個若一致性的文件，因爲在進行快照的時候服務器不會阻塞
通過快照日誌和事務日誌可以把任意zk節點還原到任意時間點的數據
寫操作的流程
- 接受寫操作：集羣中的任意節點都可以接受寫操作，但是當非leader節點接收到寫請求後，會把當前的請求轉發給leader節點
- 協調寫操作：leader接收到寫操作請求後，會爲這次的寫分配一個唯一的事務ID（ZXID）然後把這次事務廣播出去
- 記錄數據：當大多數節點響應這次事務提議後，進行事務的提交和內存數據庫的應用
- 記錄快照：當事務日誌記錄的次數達到一定數量後(默認10W)，將內存數據庫進行一次備份，持久化保存到磁盤上