一致性級別劃分

關於分散式系統一致性級別的劃分，有些文章劃分為強一致性，順序一致性以及弱一致性。

最終一致性屬於弱一致性，最終一致性根據更新資料後各程式訪問到資料的時間和方式的不同劃分為：

• 因果一致性、
• “讀己之所寫（read-your-writes）”一致性、
• 會話（Session）一致性、
• 單調（Monotonic）讀一致性、
• 單調寫一致性

另一種，根據一致性的強弱程度不同，直接劃分為強一致性、單調一致性、會話一致性、最終一致性和弱一致性。

最終一致性和順序一致性的區別

最終一致性和順序一致性的差別非常大。

順序一致性是更強的一致性模型，最終一致性模型是非常弱的一致性模型。可以這麼說，滿足順序一致性的系統一定滿足最終一致性，但滿足最終一致性的系統不一定滿足順序一致性。比如，Zookeeper是順序一致性，Zookeeper也滿足最終一致性；Cassandra是最終一致性，但Cassandra不滿足順序一致性。

Zookeeper一致性級別分析

博文《線性一致性(Linearizability)是併發控制的基礎》中提到【在分散式領域中，我們也會說線性一致性，例如Zookeeper是線性一致性的，再比如分散式領域著名的CAP定理中的C，也是指線性一致性。】

作者的意思是他在文章中提到的【Zookeeper是線性一致性的】是為了舉例說明線性一致性也會用來描述分散式系統，因為線性一致性最早在平行計算領域提出。

其實，各個領域的線性一致性都是一樣的。線性一致性最早在平行計算領域提出，現在在分散式領域、資料庫領域都在用，含義是一樣的。我們可以把線性一致性稱作為強一致性，或者原子一致性。準確的來說，Zookeeper如果只有寫請求時，是線性一致性的；如果從讀和寫的角度來說是順序一致性的。

Zookeeper是不是線性一致性呢

嚴格說【Zookeeper如果只有寫請求時，是線性一致性的；如果從讀和寫的角度來說是順序一致性的】

Zookeeper保證哪種級別的一致性

正如上面所說，Zookeeper如果只有寫請求時，是線性一致性的；如果從讀和寫的角度來說是順序一致性的。

如何理解Zookeeper的順序一致性請參看 juejin.im/post/5d5a2a…

Zookeeper的單調一致性分析

而根據 Zookeeper 的 ZAB 協議來看，Zookeeper 保證的一致性是單調一致性（任何時刻，任何使用者一旦讀到某個資料在某次更新後的值，那麼就不會再讀到比這個值更舊的值。也就是說，獲取的資料順序必是單調遞增的。）

原因：

• 假設有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（不參與選舉）節點緩解這個問題.