資料一致性原則：在一個分散式資料庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態（最終一致性） 所以客戶端可以獲取最近一段時間資料，不一定是最新的（最終一致性） Zookeeper是分散式協調服務 ,它是叢集的管理者,監視著叢集中各個節點的狀態，根據節點的反饋進行下一步合理操作。 Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以後，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態 事務順序一致性

，zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。 每個Server在工作過程中有三種狀態： LOOKING：當前Server不知道leader是誰，正在搜尋 LEADING：當前Server即為選舉出來的leader FOLLOWING：leader已經選舉出來，當前Server與之同步 寫請求（兩步提交） 注：1.在Client向Follwer發出一個寫的請求 2.Follwer把請求傳送給Leader 3.Leader接收到以後開始發起投票並通知Follwer進行投票 4.Follwer把投票結果傳送給Leader 5.Leader將結果彙總後如果需要寫入，則開始寫入同時把寫入操作通知給Leader，然後commit; 6.Follwer把請求結果返回給Client zookeeper用處 命名服務：在zookeeper的檔案系統裡建立一個目錄，即有唯一的path。在我們使用tborg無法確定上游程式的部署機器時即可與下游程式約定好path，通過path即能互相探索發現（dubbo）。 配置管理：把應用配置放置zookeeper上去,儲存在 Zookeeper 的某個目錄節點中，然後所有相關應用程式對這個目錄節點進行監聽，一旦配置資訊發生變化，每個應用程式就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置資訊應用到系統中就好 叢集管理：節點（機器）增刪及Master選取。節點增刪：所有機器約定在父目錄GroupMembers下建立臨時目錄節點，然後監聽父目錄節點的子節點變化訊息。一旦有機器掛掉，該機器與 zookeeper的連線斷開，其所建立的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，於是，所有人都知道：它上船了。新機器加入 也是類似，所有機器收到通知：新兄弟目錄加入，highcount又有了。Master選取：所有機器建立臨時順序編號目錄節點，每次選取編號最小的機器作為master就好。 分散式鎖：基於zookeeper一致性檔案系統,實現鎖服務。鎖服務分為儲存獨佔及時序控制兩類。儲存獨佔：將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。所有客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。用完刪除自己建立的distribute_lock 節點就釋放鎖。時序控制：基於/distribute_lock鎖，所有客戶端在它下面建立臨時順序編號目錄節點，和選master一樣，編號最小的獲得鎖，用完刪除，依次方便。 佇列管理：分同步佇列,FIFO佇列（入隊與出隊），同步佇列：當一個佇列的成員都聚齊時，這個佇列才可用，否則一直等待所有成員到達。在約定目錄下建立臨時目錄節點，監聽節點數目是否是我們要求的數目。FIFO佇列：和分散式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。 Paxos演算法解決：保證每個節點執行相同的操作序列。 Paxos演算法通過投票來對寫操作進行全域性編號，同一時刻，只有一個寫操作被批准，同時併發的寫操作要去爭取選票，只有獲得過半數選票的寫操作才會被 批准（所以永遠只會有一個寫操作得到批准），其他的寫操作競爭失敗只好再發起一輪投票，就這樣，在日復一日年復一年的投票中，所有寫操作都被嚴格編號排序。編號嚴格遞增，當一個節點接受了一個編號為100的寫操作，之後又接受到編號為99的寫操作（因為網路延遲等很多不可預見原因），它馬上能意識到自己 資料不一致了，自動停止對外服務並重啟同步過程。任何一個節點掛掉都不會影響整個叢集的資料一致性（總2n+1臺，除非掛掉大於n臺）。 分散式事務：zk的分散式事務，其實也就是2階段提交，當執行一個寫操作首先提交給其中一個server，server轉發給leader，lerder發起二階段的投票，半數以上通過，執行寫操作。 CAP 一致性 分割槽容錯性 可用性 （最終一致性）