“便宜、快速、好：選擇其中兩個(gè)”？

CAP定理：你不能同時(shí)擁有蛋糕并吃掉它。

• 一致性：蛋糕始終是同樣的口味。
• 可用性：蛋糕始終可以被吃掉。
• 分區(qū)容錯(cuò)性：蛋糕可以被切成塊并共享。

CAP定理將類似的推理方法擴(kuò)展到分布式系統(tǒng)中；具體而言，它指出分布式系統(tǒng)只能提供三個(gè)中的兩個(gè)理想特性：一致性、可用性和分區(qū)容錯(cuò)性（CAP中的字母'C'，'A'和'P'）。

將數(shù)據(jù)同時(shí)保存在多個(gè)節(jié)點(diǎn)上的網(wǎng)絡(luò)，無論這些節(jié)點(diǎn)是實(shí)際的還是虛擬的計(jì)算機(jī)，都被稱為分布式系統(tǒng)。

在開發(fā)云應(yīng)用程序時(shí)，了解CAP定理非常重要，因?yàn)樗性茟?yīng)用程序都是分布式系統(tǒng)。

CAP的基本概念

讓我們更深入地了解CAP定理對(duì)分布式系統(tǒng)的三個(gè)特性的概念。

一致性

無論客戶端連接到哪個(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)為寫入已經(jīng)“成功完成”。

可用性

任何請(qǐng)求數(shù)據(jù)的客戶端都會(huì)獲得響應(yīng)，即使網(wǎng)絡(luò)中的一個(gè)或多個(gè)節(jié)點(diǎn)不可用。這就是可用性。

換句話說，分布式系統(tǒng)中的每個(gè)運(yùn)行節(jié)點(diǎn)都將毫無例外地對(duì)每個(gè)請(qǐng)求提供合法的答案。

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

分布式系統(tǒng)內(nèi)部的通信中斷稱為分區(qū)。這可以被看作是系統(tǒng)中兩個(gè)節(jié)點(diǎn)之間的連接丟失或暫時(shí)延遲。

術(shù)語“分區(qū)容忍性”是指盡管在構(gòu)成系統(tǒng)的各個(gè)節(jié)點(diǎn)之間的通信中出現(xiàn)任意數(shù)量的故障，集群的功能仍必須得到維護(hù)。

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

img

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

現(xiàn)在，NoSQL數(shù)據(jù)庫根據(jù)它們提供的兩個(gè)CAP原則進(jìn)行分類，這兩個(gè)原則分別是：

CP數(shù)據(jù)庫提供一致性和分區(qū)容忍性，但以犧牲可用性為代價(jià)。如果在任意兩個(gè)節(jié)點(diǎn)之間發(fā)生分區(qū)，系統(tǒng)需要將非一致的節(jié)點(diǎn)停止（即使其無法訪問），直到分區(qū)問題得到解決。

AP數(shù)據(jù)庫在數(shù)據(jù)的一致性方面存在犧牲，但提供可用性和分區(qū)容忍性。當(dāng)分區(qū)發(fā)生時(shí)，網(wǎng)絡(luò)中的所有節(jié)點(diǎn)仍然可訪問，但靠近分區(qū)開頭或結(jié)尾的節(jié)點(diǎn)可能提供比其他節(jié)點(diǎn)更舊的數(shù)據(jù)版本。（一旦分區(qū)問題得到解決，AP數(shù)據(jù)庫通常會(huì)重新同步節(jié)點(diǎn)，以糾正可能引入到系統(tǒng)中的任何不一致性。）

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

由于分區(qū)在分布式系統(tǒng)中是不可避免的，我們故意將CA數(shù)據(jù)庫類型放在列表的最后。因此，雖然可以在理論上討論CA分布式數(shù)據(jù)庫的概念，但實(shí)際上，這樣的數(shù)據(jù)庫根本不存在。然而，如果你覺得你的分布式應(yīng)用需要CA數(shù)據(jù)庫，并不意味著你不能擁有這樣一個(gè)數(shù)據(jù)庫。

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

CAP定理和MongoDB

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

MongoDB是一個(gè)CP數(shù)據(jù)存儲(chǔ)，因?yàn)樗軌蛟诒３謹(jǐn)?shù)據(jù)一致性的同時(shí)解決網(wǎng)絡(luò)分區(qū)問題，但以犧牲可用性為代價(jià)，正如CAP定理所描述的那樣。

在MongoDB中，一個(gè)復(fù)制集（replica set）只能有一個(gè)主節(jié)點(diǎn)來處理所有寫操作。復(fù)制集中的次要節(jié)點(diǎn)復(fù)制主節(jié)點(diǎn)的事務(wù)日志，并使用它來更新自己的數(shù)據(jù)副本。客戶端默認(rèn)從主節(jié)點(diǎn)讀取數(shù)據(jù)，但可以通過設(shè)置讀偏好來更改這一行為。

如果原始節(jié)點(diǎn)故障，最近操作日志最多的次要節(jié)點(diǎn)將被提升為主節(jié)點(diǎn)。只要所有從節(jié)點(diǎn)都趕上了新的主節(jié)點(diǎn)，集群就會(huì)恢復(fù)可訪問性。在此期間，沒有客戶端可以發(fā)送寫請(qǐng)求，因此數(shù)據(jù)在整個(gè)網(wǎng)絡(luò)上是同步的。

CAP定理（AP）和Cassandra

Apache軟件基金會(huì)開發(fā)和分發(fā)Cassandra，這是一個(gè)自由開源的NoSQL數(shù)據(jù)庫。它以寬列數(shù)據(jù)庫的形式進(jìn)行分布式數(shù)據(jù)存儲(chǔ)。由于其無主節(jié)點(diǎn)的設(shè)計(jì)，Cassandra沒有像MongoDB那樣的單點(diǎn)故障。

Cassandra是一個(gè)AP數(shù)據(jù)庫，因?yàn)樗鼭M足了一些但不是所有的一致性、可用性和分區(qū)容忍性（CAP）要求。由于缺乏主節(jié)點(diǎn)，Cassandra集群中的所有節(jié)點(diǎn)始終處于運(yùn)行狀態(tài)至關(guān)重要。另一方面，Cassandra通過允許客戶端隨時(shí)向任何節(jié)點(diǎn)寫入數(shù)據(jù)并迅速解決不一致性問題來提供最終一致性。

Cassandra具有“修復(fù)”功能，以幫助節(jié)點(diǎn)趕上其對(duì)等節(jié)點(diǎn)，因?yàn)橹挥性诰W(wǎng)絡(luò)分裂的情況下數(shù)據(jù)才會(huì)變得不一致，并且不一致性會(huì)迅速得到糾正。然而，持續(xù)的可用性會(huì)產(chǎn)生高性能的系統(tǒng)，在某些情況下可能值得付出代價(jià)。

結(jié)論

如果你正在創(chuàng)建基于微服務(wù)的分布式項(xiàng)目，了解CAP定理可以幫助你選擇合適的數(shù)據(jù)庫。例如，如果你可以接受最終一致性（而不是嚴(yán)格一致性），但需要快速迭代數(shù)據(jù)模型并進(jìn)行水平擴(kuò)展，那么像Cassandra或Apache CouchDB這樣的AP數(shù)據(jù)庫可能能滿足你的需求并簡化部署。

另一方面，如果你的應(yīng)用程序的成功取決于數(shù)據(jù)的可靠性，例如電子商務(wù)或支付服務(wù)，那么關(guān)系型數(shù)據(jù)庫如PostgreSQL可能是最佳選擇。