879
《ZooKeeper官方指南》一致性保障
一致性保障
ZooKeeper是一個高性能，可擴展的服務。雖然讀比寫更快，但在設計上，它的讀操作和寫操作都很快。之所以會出現讀比寫更快，是因為在某些“讀”的情況下，ZooKeeper 可以使用比較舊的數據，這得益於ZooKeeper的一致性保障：
連續一致性
來自客戶端的更新請求會按照它們發送的順序被應用。
原子性
更新要麼成功，要麼失敗——不會出現部分成功的（更新操作）結果
單係統圖像
一個客戶端將會看到和它連接的服務器相同的服務視圖。
可靠性
一旦一個更新被應用了，它（更新）將會從此一直存在，直到一個客戶端再次更新。從這個保障可以得出兩個推論：
1.如果一個客戶端獲得一個成功的返回碼，更新將會一直被應用。在一些失敗的情況下（比如連接錯誤，超時等）客戶端將不會知道更新被應用了與否。我們對使失敗（錯誤）降到最低采取了行動，但這個保障僅僅當返回碼是正確的時侯才會出現。（這是一種在Paxos算法中被稱為單調性的情況）。
2、任何通過讀請求或成功更新的已被客戶端看到的更新，當它處於從服務器錯誤中恢複的狀態時（操作）將不能被回滾。
及時性
係統的客戶端視圖被強製性定為在一個合適的時間範圍內（在命令的數十秒內）是最新的。係統的改變在這個範圍內既不會被客戶端看見，客戶端也不會知道服務的運行中斷。
使用這些一致性保障來建造一些更高級的功能，如leader選舉、障礙、隊列以及在ZooKeeper客戶端（附件不被ZooKeeper需要）進行唯一的可撤銷的鎖的讀/寫是簡單的。更多詳情請見”Recipes and Solutions”。
| Note |
| 有時開發者會誤以為有那麼一些ZooKeeper實際上並不會保證做到的保障存在,它們是：同一時間一致的跨客戶端視圖
ZooKeeper並不保證在某一時刻，兩個不同的客戶端會接受到完全一致的ZooKeeper視圖的數據。這是由一些因素導致的，如網絡延遲，或客戶端可能會在另一個客戶端獲取到改變通知之前執行一個更新。考慮一下存在兩個客戶端的情況，如客戶端A和客戶端B。如果客戶端A將一個znode /a的值從0設為1，然後告訴客戶端B去讀/a,那麼客戶端B可能會因為它連接到的服務器的不同而讀取到那個舊的值0.如果客戶端A和B讀取到相同的值是重要的，那麼客戶端B應該在它執行讀操作之前就從ZooKeeper的API方法裏調用sync（）方法。 所以，ZooKeeper它本身並不保證改變是在所有服務器間同步發生的，但ZooKeeper基元(注：primitives)可以被用來建造那些提供有效客戶端同步的更高級的功能。（更多詳情請見“ZooKeeper Recipes”.[tbd:..]） |
最後更新：2017-05-19 14:32:22