一個分散式系統最多隻能同時滿足一致性（Consistency）、可用性（Availability）和分割槽容錯性（Partition tolerance）這三項中的兩項。

注意： ACID和BASE代表兩種截然相反的設計哲學。ACID是傳統資料庫常用的設計概念，追求強一致性模型。BASE支援的大型分散式系統，提出通過犧牲強一致性獲取高可用性 。

BASE是指基本可用、軟狀態、最終一致性。

• 基本可用（Basically Available）：是指分散式系統出現故障的時候，允許損失部分可用性，即保證核心可用。比如過年時使用微信紅包的使用者量劇增，為了保證核心的功能可用，微信可能會將一部分其他的功能禁用，這就是損失部分可用性的體現。
• 軟狀態（Soft State）：軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分散式儲存中一般一份資料至少會有三個副本，允許不同節點間副本同步的額延時就是軟狀態的體現。MySQL Replication的非同步複製就是該狀態的一種體現。
• 最終一致性（Eventual Consistency）：最終一致性是指系統中的所有資料副本經過一定時間後，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。

CAP的定義

Consistency 一致性

一致性指“all nodes see the same data at the same time”

服務端： 主要解決更新如何複製分佈到整個系統，以保證資料最終一致性。

客戶端 ：主要指的是多併發訪問時更新過的資料如何獲取的問題。

注意： 一致性是因為有併發讀寫才有的問題，因此在理解一致性的問題時，一定要結合考慮併發讀寫的場景 。多程序併發訪問時，更新過的資料在不同程序如何獲取的不同策略，決定了不同的一致性。對於關係型資料庫，要求更新過的資料能被後續的訪問都能看到，這是強一致性 。如果能容忍後續的部分或者全部訪問不到，則是弱一致性。 如果經過一段時間後要求能訪問到更新後的資料，則是最終一致性 。

Availability 可用性

可用性指“reads all writes always succeed”

Partition Tolerance 分割槽容錯性

分割槽容錯性指“the system continues to operate despite arbitrary message loss or failure of part of the system” ，即分散式系統在遇到節點或者網路分割槽故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。

分割槽容錯性和擴充套件性緊密相關。在分散式應用中，可能因為一些分散式的原因導致系統無法正常運轉。好的分割槽容錯性要求能夠使應用雖然是一個分散式系統，而看上去卻好像是一個可以運轉正常的整體。比如現在的分散式系統中有某一個或者幾個機器宕掉了，其他剩下的機器還能正常運轉滿足系統需求，或者是機器之間網路異常，將分散式系統分隔為獨立的幾個部分，各個部分還能維持分散式系統的運作，這樣就具有好的分割槽容錯性。

CAP理論取捨

• CA without P：如果不要求P（不允許分割槽），則C（強一致性）和A（可用性）是可以保證的。但是P是分散式系統不可避免的問題。傳統的關係資料庫滿足CA
• CP without A：如果不要求A（可用性），相當於每個請求都需要Server之間強一致，而P（不允許分割槽）會導致同步時間無限延長，如此CP也是可以保證的，很多傳統資料庫分散式事務都屬於這種模式。
• AP without C：如果要求A（可用性）和P（不允許分割槽），則需要放棄一致性。一旦分割槽發生，節點之間失去聯絡，為了高可用，每個節點只能用本地資料提供服務，而這樣會導致全域性資料的不一致。現在眾多NoSQL都屬於此類。

注意： CAP理論，只能根據場景定奪，適合的才是最好的。

參考資料