Zookeeper一致性級別

一致性級別劃分

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

最終一致性屬於弱一致性，最終一致性根據更新數據後各進程訪問到數據的時間和方式的不一樣劃分爲：

• 因果一致性、
• 「讀己之所寫（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（不參與選舉）節點緩解這個問題.