當集群中的learner完成了初始化狀態同步，那麼整個zk集群就進入到了正常工作模式了。
如果集群中的learner 節點收到客戶端的事務請求，那麼這些learner會將請求**給leader伺服器。然後再執行如下過程：
leader接收到事務請求後，為事務賦予乙個全域性唯一的64位自增id，即zxid，通過zxid的大小比較即可實現事務的有序性管理，然後將事務封裝成乙個proposal。
leader 根據follower 列表獲取到所有的follower，然後將proposal通過這些follower的佇列將提案傳送給各個follower。
當follower 接收到提案後，會先將提案的zxid與本地記錄的事務日誌中的最大zxid進行比較。若當前提案的zxid大於最大zxid，則將當前提案記錄到本地事務日誌中，並向leader 返回乙個ack。
當leader接收到過半的acks後，leader 就會向所有follower 的佇列傳送commit 訊息，向所有observer的佇列傳送proposal。
當follower接收到commit訊息後，就會將事務正式更新到本地。當observer 收到proposal 後，會直接將事務更新到本地。
無論是follower 還是 observer ，在同步完成後都需要向leader 傳送成功ack。
**observer 數量並不是越多越好，一般與follower數量相同。**因為observer數量的增多隨不會增加事務操作壓力，但需要從leader同步資料，**observer同步資料的時間是小於等於follower同步資料時間的。**當follower同步資料完成，leader的observer列表中的observer主機將結束同步，那些完成同步的observer將進入到另乙個對外提供服務的列表。那麼，那些沒有同步了資料無法提供服務的observer主機就形成了資源的浪費。
所以，對於事務操作發生頻繁的系統，不建議使用過多的observer。
leader中儲存的observer列表其實有兩個：
all： 包含所有的observer。
service：已經完成了從leader 同步資料的任務。service <= all.其是動態的。
leader中儲存的follower列表其實也有兩個：
all：要求其中必須有過半的follower向leader 反饋ack
service：已經完成了從leader 同步資料的任務。service <= all.其是動態的。
zookeeper授權模式
zk的許可權訪問acl。由schema id permission來定義的。其中schema包括 world auth digest ip,其中world是預設許可權，而且是所有人都可以對節點做任意操作，id的話就是不同schema下的標識，比如。auth digest則代表使用者名稱和密碼，ip代...
Zookeeper基礎使用
啟動zk服務 bin zkserver.sh start 檢視zk服務狀態 bin zkserver.sh status 停止zk服務 bin zkserver.sh stop 重啟zk服務 bin zkserver.sh restart 連線伺服器 zkcli.sh server 127.0.0....
zookeeper選主和同步機制
在上篇博文 zookeeper輕鬆入門 中，已經詳細介紹了zookeeper的架構和資料互動的過程。我們已經知道zookeeper的更新操作具有強一致性，而這一過程正是通過leader廣播實現的。本篇博文就在此基礎上詳細介紹一下zookeeper的選舉機制的同步機制。zookeeper的核心是原子廣...