在足球比賽裡，乙個球員在一場比賽中進三個球，稱之為帽子戲法(hat-trick)。在分布式資料系統中，也有乙個帽子原理(cap theorem)，不過此帽子非彼帽子。cap原理中，有三個要素：
cap原理指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。因此在進行分布式架構設計時，必須做出取捨。而對於分布式資料系統，分割槽容忍性是基本要求，否則就失去了價值。因此設計分布式資料系統，就是在一致性和可用性之間取乙個平衡。對於大多數web應用，其實並不需要強一致性，因此犧牲一致性而換取高可用性，是目前多數分布式資料庫產品的方向。
當然，犧牲一致性，並不是完全不管資料的一致性，否則資料是混亂的，那麼系統可用性再高分布式再好也沒有了價值。犧牲一致性，只是不再要求關係型資料庫中的強一致性，而是只要系統能達到最終一致性即可，考慮到客戶體驗，這個最終一致的時間視窗，要盡可能的對使用者透明，也就是需要保障「使用者感知到的一致性」。通常是通過資料的多份非同步複製來實現系統的高可用和資料的最終一致性的，「使用者感知到的一致性」的時間視窗則取決於資料複製到一致狀態的時間。
最終一致性(eventually consistent)
對於一致性，可以分為從客戶端和服務端兩個不同的視角。從客戶端來看，一致性主要指的是多併發訪問時更新過的資料如何獲取的問題。從服務端來看，則是更新如何複製分布到整個系統，以保證資料最終一致。一致性是因為有併發讀寫才有的問題，因此在理解一致性的問題時，一定要注意結合考慮併發讀寫的場景。
從客戶端角度，多程序併發訪問時，更新過的資料在不同程序如何獲取的不同策略，決定了不同的一致性。對於關係型資料庫，要求更新過的資料能被後續的訪問都能看到，這是強一致性。如果能容忍後續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間後要求能訪問到更新後的資料，則是最終一致性。
最終一致性根據更新資料後各程序訪問到資料的時間和方式的不同，又可以區分為：
上述最終一致性的不同方式可以進行組合，例如單調讀一致性和讀己之所寫一致性就可以組合實現。並且從實踐的角度來看，這兩者的組合，讀取自己更新的資料，和一旦讀取到最新的版本不會再讀取舊版本，對於此架構上的程式開發來說，會少很多額外的煩惱。從服務端角度，如何盡快將更新後的資料分布到整個系統，降低達到最終一致性的時間視窗，是提高系統的可用度和使用者體驗非常重要的方面。對於分布式資料系統：
如果w+r>n，寫的節點和讀的節點重疊，則是強一致性。例如對於典型的一主一備同步複製的關係型資料庫，n=2,w=2,r=1，則不管讀的是主庫還是備庫的資料，都是一致的。
如果w+r<=n，則是弱一致性。例如對於一主一備非同步複製的關係型資料庫，n=2,w=1,r=1，則如果讀的是備庫，就可能無法讀取主庫已經更新過的資料，所以是弱一致性。
對於分布式系統，為了保證高可用性，一般設定n>=3。不同的n,w,r組合，是在可用性和一致性之間取乙個平衡，以適應不同的應用場景。
CAP原理與最終一致性
cap原理 cap theorem 在足球比賽裡，乙個球員在一場比賽中進三個球，稱之為帽子戲法 hat trick 在分布式資料系統中，也有乙個帽子原理 cap theorem 不過此帽子非彼帽子。cap原理中，有三個要素 cap原理指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。因此在進行...
CAP原理與最終一致性 強一致性 透析
在足球比賽裡，乙個球員在一場比賽中進三個球，稱之為帽子戲法 hat trick 在分布式資料系統中，也有乙個帽子原理 cap theorem 不過此帽子非彼帽子。cap原理中，有三個要素 cap原理指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。因此在進行分布式架構設計時，必須做出取捨。而對...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...