怎么分析Zookeeper的一致性

本篇文章為大家展示了怎么分析Zookeeper的一致性，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

Zookeeper 是一種高性能、可擴展的服務。 Zookeeper 的讀寫速度非常快，并且讀的速度要比寫的速度更快。另外，在進行讀操作的時候， ZooKeeper 依然能夠為舊的數據提供服務。這些都是由于 ZooKeepe 所提供的一致性保證，它具有如下特點：

【Zookeeper提供的一致性是弱一致性,首先數據的復制有如下規則:zookeeper確保對znode樹的每一個修改都會被復制到集合體中超過半數的機器上。那么就有可能有節點的數據不是最新的而被客戶端訪問到。并且會有一個時間點,在集群中是不一致的.

也就是Zookeeper只保證最終一致性, 但是實時的一致性可以由客戶端調用自己來保證,通過調用sync()方法.】

順序一致性

客戶端的更新順序與它們被發送的順序相一致。

原子性

更新操作要么成功要么失敗，沒有第三種結果。

單系統鏡像

無論客戶端連接到哪一個服務器，客戶端將看到相同的 ZooKeeper 視圖。

【如果數據不一致,怎么能夠保證看到相同的視圖? 插入/刪除/修改都會對數據結構有影響】

可靠性

一旦一個更新操作被應用，那么在客戶端再次更新它之前，它的值將不會改變。。這個保證將會產生下面兩種結果：

1 ．如果客戶端成功地獲得了正確的返回代碼，那么說明更新已經成果。如果不能夠獲得返回代碼（由于通信錯誤、超時等等），那么客戶端將不知道更新操作是否生效。

2 ．當從故障恢復的時候，任何客戶端能夠看到的執行成功的更新操作將不會被回滾。

實時性

在特定的一段時間內，客戶端看到的系統需要被保證是實時的（在十幾秒的時間里）。在此時間段內，任何系統的改變將被客戶端看到，或者被客戶端偵測到。

【偽實時性,太讓人誤解了,直白點說就是數據可以在十幾秒Sync到各個節點,保證最終一致性. 我第一時間看到這個實時性的時候,我就好奇,Oracle RAC花了老鼻子勁才保證了實時性和一致性,Zookeeper是如何輕松做到的,原來是個假的,還說的那么讓人誤會. 】

給予這些一致性保證， ZooKeeper 更高級功能的設計與實現將會變得非常容易，例如： leader 選舉、隊列以及可撤銷鎖等機制的實現。

【

用分布式系統的CAP原則來分析Zookeeper.

1)C: Zookeeper保證了最終一致性,在十幾秒可以Sync到各個節點.

2)A: Zookeeper保證了可用性,數據總是可用的,沒有鎖.并且有一大半的節點所擁有的數據是最新的,實時的. 如果想保證取得是數據一定是最新的,需要手工調用Sync()

3)P: 有2點需要分析的.

          節點多了會導致寫數據延時非常大,因為需要多個節點同步.

          節點多了Leader選舉非常耗時, 就會放大網絡的問題. 可以通過引入observer節點緩解這個問題.

】

上述內容就是怎么分析Zookeeper的一致性，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。