zookeeper 一致性保障

zookeeper是一個高性能,可擴展的服務.zookeeper的讀操做
和寫操做的設計目標就是速度快,不過zookeeper的讀比寫快,在讀的場景下,zookeeper能夠將讀的壓力分散到不一樣的follow服務節點上,並且須要讀取的數據大部分是已經被更新好了的'舊'的數據,而寫操做須要在各個節點間保證一致性同步.保證數據的一致性同步是zookeeper的核心功能,他提供以下保證:

• 順序一致性: 從客戶端發送過來的命令是按照時間前後順序有序執行的(注:更新操做是leader節點執行的,讀取請求leader/follow均可以執行)
• 原子性: 更新操做的結果要麼成功要麼失敗,沒有部分紅功或者部分失敗的狀況,不會產生部分結果
• 單一的一致系統映像:客戶端讀取到數據都是一致的,也就是講對於一個zookeeper集羣來說,同一時間節點上客戶端在任何一個節點讀取的數據都是一致的,即便有些特殊狀況下zookeeper發生了故障轉移,客戶端也不會讀取到髒的數據

• 可靠性: 一旦更新被應用了,那麼數據就會被持久化了不會被丟失或者篡改除非客戶端後面主動的修改這個值,這個保證有2個推論:

  • 若是客戶端獲得了一個操做的success code,那麼這個更新操做就被應用了.一個服務端錯誤產生了()那麼客戶端是不知道的操做是成功仍是失敗了,咱們採起的步驟是儘可能減小失敗,但只有返回成功代碼的操做纔有保證(這在Paxos中稱爲單調條件)
  • 任何被客戶端看到的數據,也就是當前看到的最新的數據或者被成功更新後的最新的數據,即便服務器因爲故障而從新恢復後也不會被回滾爲舊或者髒數據(丟失,篡改,髒數據,舊數據)
• 及時性:保證系統的客戶端視圖在必定的時間範圍內(以數十秒爲數量級)是最新的.在此範圍內,客戶機要麼看到系統更改要麼檢測到服務中斷

使用這些一致性保證很容易在ZooKeeper客戶端上創建更高級別的功能,好比leader選舉、障礙、隊列和讀/寫可撤銷鎖(不須要添加ZooKeeper),更多狀況請看:Recipes and Solutions

注意

一些開發者會錯誤的認爲除了上面講到的一致性保障外,還有例外的一種保障zookeeper不能支持,這保障就是時間上徹底同時的一致性跨客戶端視圖:zookeeper沒法確保集羣中的任意一個節點都會徹底同時的執行一個同一個操做,由於網絡通訊是有延遲的,一個客戶端更新操做是在例外一個客戶端接到數據更新通知的前面發生的,考慮下面的場景,有A,B共2個客戶端,若是A更新了/a節點的數據由0到1,而後告訴B客戶端去讀取/a,客戶端B可能會讀到/a的舊數據,取決於B是從那個節點讀取/a(讀取leader是最新的,可是讀取follow多是舊的).若是客戶端A和客戶端B讀取相同的值很重要,客戶端B應該在執行讀取操做以前調用zookeeper API方法中的sync()方法.因此，zookeeper自己並不能保證在全部服務器上同步發生變化，可是zookeeper原語能夠用來構建更高級別的函數，提供有用的客戶端同步.

參考:

• Consistency Guarantees
• 《ZooKeeper官方指南》一致性保障

本文原創連接: zookeeper 一致性保障