CAP定理，也稱為布魯爾定理（Brewer's Theorem），是由加州大學伯克利分校的計算機科學家Eric Brewer提出的。CAP是指一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）三個系統屬性。在一個分布式系統中，CAP定理聲明：

一致性

無論客戶端連接到哪個節點，它們總是會同時看到相同的數據，這就是我們所說的一致性。為了實現這一點，每次將數據寫入一個節點時，都必須立即將其發送或復制到系統中的所有其他節點，然后才能認為寫入已“成功完成”。

可用性

即使網絡中的一個或多個節點不可用，所有發出數據請求的客戶端都會得到響應。這就是我們談論的可用性。另一種表達方式是，分布式系統中的每個操作節點都將會為每個請求提供合法的答案。

分區容錯性

分布式系統內部的通信中斷稱為分區。這可以被認為是系統中兩個節點之間丟失或暫時延遲的鏈路。術語“分區容錯性”是指盡管構成系統的各個節點之間的通信出現任意數量的故障，但仍必須維持集群的功能。

CAP定理指出，在任何給定的時刻，一個分布式系統只能滿足上述三個保證中的兩個。換言之，如果一個系統已經必須滿足分區容錯性（P），那么它必須在一致性（C）和可用性（A）之間進行權衡。

例如，當一個網絡分區故障發生時，系統管理員可能需要選擇：

• 放棄一致性（C）以保持可用性（A）和分區容錯性（P），這種情況下，系統會繼續處理事務，但是結果可能不一致。
• 或者放棄可用性（A）以保持一致性（C）和分區容錯性（P），這樣的話，在故障消除前，系統不會執行任何可能違反數據一致性規則的操作。

不同 NoSQL 數據庫的 CAP

NoSQL 數據庫是在分散網絡上運行的應用程序的最佳選擇。與其垂直可擴展的 SQL（關系）前身相比，NoSQL 數據庫在設計上具有水平可擴展性和分布式性。這意味著它們能夠在由多個鏈接節點組成的開發網絡上快速擴展。

NoSQL 數據庫現在根據它們提供的兩個 CAP 標準進行分類，它們是：

CP 數據庫提供一致性和分區容錯性，但會犧牲其可用性。如果任意兩個節點之間發生分區，系統需要將不一致的節點停止（即使其不可訪問），直到分區被糾正。

AP 數據庫提供可用性和分區容錯性，但代價是數據的一致性。當分區發生時，網絡中的所有節點繼續可訪問，但更靠近分區開頭或結尾的節點可能提供比其他節點更舊版本的數據。（一旦分區問題得到糾正，AP 數據庫通常會重新同步節點，以糾正系統中可能引入的任何不一致情況。）

CA 數據庫確保系統中所有節點的數據一致且可訪問。但是，如果系統中任意兩個節點之間存在分區，則無法完成此任務，從而無法提供容錯功能。

由于分區在分布式系統中是不可避免的，因此我們特意將 CA 數據庫類型放在列表的最后。因此，雖然理論上可以討論CA分布式數據庫的概念，但實際上，這樣的數據庫根本不存在。

包括 PostgreSQL、MySQL、SQLServer在內的各種關系數據庫都提供一致性和可用性，并且它們可以跨多個節點進行復制以進行分布式部署，但它們都不是真正的分布式數據庫。

CAP 定理和 MongoDB

MongoDB 中的數據存儲為 BSON（二進制 JSON）文檔，使其成為常見的 NoSQL 數據庫管理系統。它廣泛用于大規模、實時、分布式應用。

MongoDB 是一種 CP 數據存儲，因為它能夠解決網絡分區問題，同時以犧牲可用性為代價保持數據一致，正如 CAP 定理所描述的那樣。

在 MongoDB 中，只能有一個主節點來處理給定副本集的所有寫入。副本集中的輔助節點復制主節點的事務日志并使用它來更新自己的數據副本。默認情況下，客戶端從主節點讀取，但他們可以通過設置讀取首選項來更改此設置。
如果原節點宕機，具有最新操作日志的Secondary節點將被提升為主角色。一旦所有從屬節點趕上新的主節點，集群將再次變得可訪問。由于在此期間沒有客戶端可以發送寫請求，因此數據在整個網絡中同步。

CAP 定理 (AP) 和 Cassandra

Apache軟件基金會開發的 Cassandra，是一個免費的開源 NoSQL 數據庫。以寬列數據庫的形式進行分布式數據存儲。由于其無主設計，Cassandra 不存在像 MongoDB 那樣的單點故障。
Cassandra 是一個 AP 數據庫，因為它滿足一致性、可用性和分區容錯性 (CAP) 的部分但不是全部要求。由于缺少主節點，Cassandra 集群中的所有節點始終保持運行狀態至關重要。另一方面，Cassandra 通過允許客戶端隨時寫入任何節點并及時解決差異來提供最終一致性。
Cassandra 具有“修復”功能，可以幫助節點趕上其對等節點，因為數據只會在網絡分裂的情況下變得不一致，但差異會很快得到糾正。另一方面，持續的可用性在注重高性能的系統中尤為重要，在某些情況下犧牲一致性是值得的。

結論

如果你正在創建基于微服務的分布式項目，了解 CAP 定理可以幫助你選擇正確的數據庫。例如，如果你可以接受最終（而不是嚴格）一致性，但需要快速迭代數據模型并水平增長，那么像 Cassandra 或 Apache CouchDB 這樣的 AP 數據庫可能會滿足你的需求并簡化部署。另一方面，如果你的應用程序注重數據的可靠性（就像在電子商務或支付服務中一樣），那么像 PostgreSQL 這樣的關系數據庫可能是最佳選擇。