[TOC] # 簡介 paxos目標是構建一個去中心化的,通用的分布式一致性算法.而且**paxos算法只在乎數據的一致性而并不關心事務請求的順序**,這一點不能滿足zk的要求 因為zk的命名空間是一個樹形結構,對執行的順序有嚴格要求.于是zk借助了paxos過半提交的思想將兩階段提交進行優化改造,ZAB就這樣誕生了. # 角色 zab協議中有三種角色 * leader:所有寫的請求首先都會轉發到leader節點上,leader節點上的數據變更會同步到集群的follower節點上 * follower:負責同步leader節點的數據,并提供數據的查詢功能.當leader節點失效的時候有權利參與投票選舉 * observer:同步leader節點的數據,并提供數據的查詢功能.沒有投票選舉.observer的設計目的是提高集群的查詢性能 # 和paxos不同 zab并不是一個無中心化的架構,在任意時刻zab都保持有且僅有一個leader節點,所有的更新事務都只能由這個leader發起. 并且當一個leader失效后,**新的leader只有在之前leader事務都被處理之后才能發起行的事務** 通過這種機制,zab協議保證了全局的事務順序.在更新階段ZAB使用的就是一個優化過的兩階段提交,這里借助了paxos的思想,只要過半的節點prepare成功,就會發起commit請求. # 使用場景 ## 統一命名服務 zk的命名空間是一個類似于linux文件系統的樹形結構,它的每個znode都擁有唯一的路徑標識符. 利用這個特性分布式文件系統,可以將zk當做統一命名服務來使用,類型java中的JNDI ## 心跳感知 利用zk的znode臨時節點類型的特性,可以實現心跳感知功能. 例如可以在zk上創建一個根目錄,如`/cluster1`.利用znode臨時階段類型的特性,當某個集群服務進程啟動的時候,可以在/cluster1上創建代表自己服務的臨時節點,用以表示其會話狀態.由于臨時節點是會話綁定的,所以當節點存在的時候即代表正常,當進程失效的時候,節點客戶端會話也失效,這時臨時節點會被剔除. 這樣只要查看臨時節點,就能看到集群狀態了 ## 選舉 zk能夠保證當**多個客戶端同時創建一個相同路徑節點的時候,只會有一個客戶端成功.** 借用這個機制我們可以實現選舉功能,因為在同一時刻,有且僅有一個客戶端會成功創建節點,這個創建成功的客戶端就是選舉的勝者