一致性級別划分
關於分布式系統一致性級別的划分，有些文章划分為強一致性，順序一致性以及弱一致性。
最終一致性屬於弱一致性，最終一致性根據更新數據后各進程訪問到數據的時間和方式的不同划分為：
- 因果一致性、
- “讀己之所寫（read-your-writes）”一致性、
- 會話（Session）一致性、
- 單調（Monotonic）讀一致性、
- 單調寫一致性
另一種，根據一致性的強弱程度不同，直接划分為強一致性、單調一致性、會話一致性、最終一致性和弱一致性。
最終一致性和順序一致性的區別
最終一致性和順序一致性的差別非常大。
順序一致性是更強的一致性模型，最終一致性模型是非常弱的一致性模型。可以這么說，滿足順序一致性的系統一定滿足最終一致性，但滿足最終一致性的系統不一定滿足順序一致性。比如，zookeeper是順序一致性，zookeeper也滿足最終一致性；cassandra是最終一致性，但cassandra不滿足順序一致性。
ZK一致性級別分析
博文《線性一致性(Linearizability)是並發控制的基礎》中提到【在分布式領域中，我們也會說線性一致性，例如Zookeeper是線性一致性的，再比如分布式領域著名的CAP定理中的C，也是指線性一致性。】
作者的意思是他在文章中提到的【Zookeeper是線性一致性的】是為了舉例說明線性一致性也會用來描述分布式系統，因為線性一致性最早在並行計算領域提出。
其實，各個領域的線性一致性都是一樣的。線性一致性最早在並行計算領域提出，現在在分布式領域、數據庫領域都在用，含義是一樣的。我們可以把線性一致性稱作為強一致性，或者原子一致性。准確的來說，Zookeeper如果只有寫請求時，是線性一致性的；如果從讀和寫的角度來說是順序一致性的。
zookeeper是不是線性一致性呢
作者是這樣解釋的：【Zookeeper如果只有寫請求時，是線性一致性的；如果從讀和寫的角度來說是順序一致性的】
Zookeeper保證哪種級別的一致性
正如上面所說，Zookeeper如果只有寫請求時，是線性一致性的；如果從讀和寫的角度來說是順序一致性的。
如何理解Zookeeper的順序一致性請參看 https://juejin.im/post/5d5a2aa6f265da03b2153816
ZK的單調一致性分析
根據 Zookeeper 的 ZAB 協議來看，ZK 保證的一致性是單調一致性（任何時刻，任何用戶一旦讀到某個數據在某次更新后的值，那么就不會再讀到比這個值更舊的值。也就是說，獲取的數據順序必是單調遞增的。）
原因：
-
假設有2n+1個server，在同步流程中，leader 向 follower 同步數據，當同步完成的 follower 數量大於 n+1時同步流程結束，系統可接受 client 的連接請求。如果client 連接的並非同步完成的follower，那么得到的並非最新數據，但可以保證單調性。
-
假設是 follower 接收的寫請求，然后轉發給 leader 處理；leader 完成兩階段提交的機制。向所有 server 發起提案，當提案獲得超過半數（n+1）的 server 認同后，將對整個集群進行同步，超過半數（n+1）的 server 同步完成后，該寫請求完成。如果 client 連接的並非同步完成 follower，那么得到的並非最新數據，但可以保證單調性。
用分布式系統的CAP原則來分析Zookeeper
（1）C（一致性）: Zookeeper保證了順序一致性（滿足最終一致性），在十幾秒可以Sync到各個節點
（2）A（可用性）: Zookeeper保證了可用性，數據總是可用的（沒有鎖）。並且有一大半的節點所擁有的數據是最新的、實時的。 如果想保證取得是數據一定是最新的，需要手工調用Sync()
（3）P（分區容錯性）: 有兩點需要分析
- 節點多了會導致寫數據延時變大，因為更多的節點需要同步
- 節點多了Leader選舉耗時變長，從而會放大網絡的問題， 可以通過引入 observer（不參與選舉）節點緩解這個問題.