CAP定理，也稱為布魯爾定理（Brewer's Theorem），是由加州大學(xué)伯克利分校的計(jì)算機(jī)科學(xué)家Eric Brewer提出的。CAP是指一致性（Consistency）、可用性（Availability）和分區(qū)容錯(cuò)性（Partition tolerance）三個(gè)系統(tǒng)屬性。在一個(gè)分布式系統(tǒng)中，CAP定理聲明：

一致性

無論客戶端連接到哪個(gè)節(jié)點(diǎn)，它們總是會同時(shí)看到相同的數(shù)據(jù)，這就是我們所說的一致性。為了實(shí)現(xiàn)這一點(diǎn)，每次將數(shù)據(jù)寫入一個(gè)節(jié)點(diǎn)時(shí)，都必須立即將其發(fā)送或復(fù)制到系統(tǒng)中的所有其他節(jié)點(diǎn)，然后才能認(rèn)為寫入已“成功完成”。

可用性

即使網(wǎng)絡(luò)中的一個(gè)或多個(gè)節(jié)點(diǎn)不可用，所有發(fā)出數(shù)據(jù)請求的客戶端都會得到響應(yīng)。這就是我們談?wù)摰目捎眯?。另一種表達(dá)方式是，分布式系統(tǒng)中的每個(gè)操作節(jié)點(diǎn)都將會為每個(gè)請求提供合法的答案。

分區(qū)容錯(cuò)性

分布式系統(tǒng)內(nèi)部的通信中斷稱為分區(qū)。這可以被認(rèn)為是系統(tǒng)中兩個(gè)節(jié)點(diǎn)之間丟失或暫時(shí)延遲的鏈路。術(shù)語“分區(qū)容錯(cuò)性”是指盡管構(gòu)成系統(tǒng)的各個(gè)節(jié)點(diǎn)之間的通信出現(xiàn)任意數(shù)量的故障，但仍必須維持集群的功能。

CAP定理指出，在任何給定的時(shí)刻，一個(gè)分布式系統(tǒng)只能滿足上述三個(gè)保證中的兩個(gè)。換言之，如果一個(gè)系統(tǒng)已經(jīng)必須滿足分區(qū)容錯(cuò)性（P），那么它必須在一致性（C）和可用性（A）之間進(jìn)行權(quán)衡。

例如，當(dāng)一個(gè)網(wǎng)絡(luò)分區(qū)故障發(fā)生時(shí)，系統(tǒng)管理員可能需要選擇：

• 放棄一致性（C）以保持可用性（A）和分區(qū)容錯(cuò)性（P），這種情況下，系統(tǒng)會繼續(xù)處理事務(wù)，但是結(jié)果可能不一致。
• 或者放棄可用性（A）以保持一致性（C）和分區(qū)容錯(cuò)性（P），這樣的話，在故障消除前，系統(tǒng)不會執(zhí)行任何可能違反數(shù)據(jù)一致性規(guī)則的操作。

不同 NoSQL 數(shù)據(jù)庫的 CAP

NoSQL 數(shù)據(jù)庫是在分散網(wǎng)絡(luò)上運(yùn)行的應(yīng)用程序的最佳選擇。與其垂直可擴(kuò)展的 SQL（關(guān)系）前身相比，NoSQL 數(shù)據(jù)庫在設(shè)計(jì)上具有水平可擴(kuò)展性和分布式性。這意味著它們能夠在由多個(gè)鏈接節(jié)點(diǎn)組成的開發(fā)網(wǎng)絡(luò)上快速擴(kuò)展。

NoSQL 數(shù)據(jù)庫現(xiàn)在根據(jù)它們提供的兩個(gè) CAP 標(biāo)準(zhǔn)進(jìn)行分類，它們是：

CP 數(shù)據(jù)庫提供一致性和分區(qū)容錯(cuò)性，但會犧牲其可用性。如果任意兩個(gè)節(jié)點(diǎn)之間發(fā)生分區(qū)，系統(tǒng)需要將不一致的節(jié)點(diǎn)停止（即使其不可訪問），直到分區(qū)被糾正。

AP 數(shù)據(jù)庫提供可用性和分區(qū)容錯(cuò)性，但代價(jià)是數(shù)據(jù)的一致性。當(dāng)分區(qū)發(fā)生時(shí)，網(wǎng)絡(luò)中的所有節(jié)點(diǎn)繼續(xù)可訪問，但更靠近分區(qū)開頭或結(jié)尾的節(jié)點(diǎn)可能提供比其他節(jié)點(diǎn)更舊版本的數(shù)據(jù)。（一旦分區(qū)問題得到糾正，AP 數(shù)據(jù)庫通常會重新同步節(jié)點(diǎn)，以糾正系統(tǒng)中可能引入的任何不一致情況。）

CA 數(shù)據(jù)庫確保系統(tǒng)中所有節(jié)點(diǎn)的數(shù)據(jù)一致且可訪問。但是，如果系統(tǒng)中任意兩個(gè)節(jié)點(diǎn)之間存在分區(qū)，則無法完成此任務(wù)，從而無法提供容錯(cuò)功能。

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

包括 PostgreSQL、MySQL、SQLServer在內(nèi)的各種關(guān)系數(shù)據(jù)庫都提供一致性和可用性，并且它們可以跨多個(gè)節(jié)點(diǎn)進(jìn)行復(fù)制以進(jìn)行分布式部署，但它們都不是真正的分布式數(shù)據(jù)庫。

CAP 定理和 MongoDB

MongoDB 中的數(shù)據(jù)存儲為 BSON（二進(jìn)制 JSON）文檔，使其成為常見的 NoSQL 數(shù)據(jù)庫管理系統(tǒng)。它廣泛用于大規(guī)模、實(shí)時(shí)、分布式應(yīng)用。

MongoDB 是一種 CP 數(shù)據(jù)存儲，因?yàn)樗軌蚪鉀Q網(wǎng)絡(luò)分區(qū)問題，同時(shí)以犧牲可用性為代價(jià)保持?jǐn)?shù)據(jù)一致，正如 CAP 定理所描述的那樣。

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

CAP 定理 (AP) 和 Cassandra

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

結(jié)論

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