zookeeper的一致性保證在順序一致性和線性一致性之間。
寫操作在zookeeper中是線性化的，換句話說，在客戶機發出請求和接收相應響應之間的某個時間點上，每次寫操作都會自動生效。這意味著zookeeper中所有客戶端執行的寫操作可以完全按照這樣一種方式進行排序，即這些寫操作的實時排序（zookeeper的寫操作通過zxid全域性排序）。
zookeeper中的讀操作不是線性化的，因為它們可能會返回過時的資料。因為讀操作不是乙個「過半」操作，伺服器會立刻返回客戶端的讀操作。zookeeper這樣做是因為它優先考慮讀效能而不是一致性。但是讀操作在zookeeper中是順序一致性的。
總的來說，zookeeper的一致性保證是通過ordered sequential consistency or osc(u)概念來準確表述的，它介於順序一致性和線性化之間。
zookeeper的寫操作全部通過leader進行操作，並未每乙個寫操作生成事務zxid，follower節點或者observer節點必須嚴格按照zxid的順序提交寫事務，所以zookeeper集群中所有節點感知到的寫操作順序是相同的。
在這篇文章中介紹過，只要保證了所有程序感知到相同的寫操作順序，其一定保證了順序一致性。
但是zookeeper為什麼不能保證線性一致性呢？因為讀取操作可以直接在follower節點或者observer節點上執行，因為zookeeper使用了「過半」提交，所以此時讀操作發生的節點不一定含有最新的資料，所以讀取的可能是舊資料。所以在此節點之上，操作順序是不符合全域性時鐘順序的，所以其並不能保證線性一致性。
為什麼又說zookeeper是ordered sequential consistency呢？因為順序一致性，沒有全域性時鐘的限制，只需要保證單個程序中操作順序確定不變，多個程序中的寫操作是可以調整順序的，但是在zookeeper中寫操作是遵循全域性時鐘順序（遵循leader接收寫操作的時間順序）的，所以其又比普通順序一致性的多了寫操作唯一有序的限制。
zookeeper之順序一致性
由於網路延遲原因，多個客戶端訪問的資料可能不一致 但是在同一檢視裡，客戶端所訪問的資料是一致的 大概就是a客戶端在進行修改x 0變為x 1時，修改後leader節點會返回zxid給到客戶端a,如果客戶a下一次再請求zookeeper獲取讀請求時，請求到follow節點上，由於2pc協議，如果該fol...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
Zookeeper的一致性協議 Zab協議
zab協議 的全稱是zookeeper atomic broadcast zookeeper原子廣播 zookeeper 是通過 zab 協議來保證分布式事務的最終一致性。zab協議是為分布式協調服務zookeeper專門設計的一種支援崩潰恢復的原子廣播協議，是zookeeper保證資料一致性的核心...