分佈式領域CAP理論：任何一個分佈式系統都無法同時滿足Consistency(一致性)，Availability(可用性)，Partition tolerance(分區容錯性) 這三個基本需求。最多隻能滿足其中兩項。
但是，一個分佈式系統無論在CAP三者之間如何權衡，都無法徹底放棄(強)一致性（Consistency），如果真的放棄一致性，那麼就說明這個系統中的數據根本不可信，數據也就沒有意義，那麼這個系統也就沒有任何價值可言。所以，無論如何，分佈式系統的一致性問題都需要重點關注。
有的架構師在某些場景說的犧牲一致性指的是放棄數據的強一致性
什麼是數據一致性
數據一致性其實是數據庫系統中的概念。我們可以簡單地把一致性理解爲正確性或者完整性，那麼數據一致性通常指關聯數據之間的邏輯關係是否正確和完整。我們知道，在數據庫系統中通常用事務（訪問並可能更新數據庫中各種數據項的一個程序執行單元）來保證數據的一致性和完整性。而在分佈式系統中，數據一致性往往指的是由於數據的複製，不同數據節點中的數據內容是否完整並且相同。
比如在集中式系統中，有一些關鍵的配置信息，可以直接保存在服務器的內存中，但是在分佈式系統中，如何保存這些配置信息，又如何保證所有機器上的配置信息都保持一致，又如何保證修改一個配置能夠把這次修改同步到所有機器中呢？
再比如，在集中式系統中，進行一個同步操作要寫同一個數據的時候，可以直接使用事務+鎖來管理保證數據的ACID。但是，在分佈式系統中如何保證多臺機器不會同時寫同一條數據呢？
除了上面提到的同一個數據的一致性，還有一種情況也可以叫做數據的一致性：比如我們在電商網站下單，需要經歷扣減庫存、扣減紅包、扣減折扣券等一系列操作。如果庫存扣減成功，但是紅包和折扣券扣減失敗的話，也可以說是數據沒有保證一致性。
如何保證數據的一致性，是分佈式系統中必須面對的問題。
一致性模型
強一致性
當更新操作完成之後，任何多個後續進程或者線程的訪問都會返回最新的更新過的值。這種是對用戶最友好的，就是用戶上一次寫什麼，下一次就保證能讀到什麼。
但是這種實現對性能影響較大，因爲這意味着，只要上次的操作沒有處理完，就不能讓用戶讀取數據。
弱一致性
系統並不保證進程或者線程的訪問都會返回最新的更新過的值。系統在數據寫入成功之後，不承諾立即可以讀到最新寫入的值，也不會承諾具體多久之後可以讀到。但會儘可能保證在某個時間級別（比如秒級別）之後，可以讓數據達到一致性狀態。
最終一致性
弱一致性的特定形式。系統保證在沒有後續更新的前提下，系統最終返回上一次更新操作的值。在沒有故障發生的前提下，不一致窗口的時間主要受通信延遲，系統負載和複製副本的個數影響。DNS是一個典型的最終一致性系統。
爲了解決分佈式的一致性問題，在長期的研究探索過程中，涌現出了一大批經典的一致性協議和算法，其中比較著名的有二階段提交協議，三階段提交協議和Paxos算法。