在計算機領(lǐng)域，如果是初入行就算了，如果是多年的老碼農(nóng)還不懂 CAP 定理，那就真的說不過去了。CAP可是每一名技術(shù)架構(gòu)師都必須掌握的基礎(chǔ)原則啊。

現(xiàn)在只要是稍微大一點的互聯(lián)網(wǎng)項目都是采用 分布式 結(jié)構(gòu)了，一個系統(tǒng)可能有多個節(jié)點組成，每個節(jié)點都可能需要維護一份數(shù)據(jù)。那么如何維護各個節(jié)點之間的狀態(tài)，如何保障各個節(jié)點之間數(shù)據(jù)的同步問題就是大家急需關(guān)注的事情了。

CAP定理是分布式系統(tǒng)中最基礎(chǔ)的原則。所以理解和掌握了CAP，對系統(tǒng)架構(gòu)的設(shè)計至關(guān)重要。

一、什么是 CAP？

「 CAP定理 」又被稱為 布魯爾定理，它提出對于一個分布式系統(tǒng)而言，不能同時滿足以下三點：

Consisteny（一致性）

Availability（可用性）

Partition tolerance（分區(qū)容錯性）

也就是說CAP定理指明了，任何分布式系統(tǒng)只能同時滿足這三項中的兩項。

如上圖，如果是最多同時滿足兩項，那我們可以有三個組合：CA、CP、AP。在聊這三個組合之前，我們先分別看一下 Consisteny（一致性）、Availability（可用性）、Partition tolerance（分區(qū)容錯性）的含義。

假設(shè)某個系統(tǒng)當前有兩個節(jié)點A和B，兩個節(jié)點分別可以由Actor進行讀寫，兩個節(jié)點之間的數(shù)據(jù)會自動完成同步。

Consisteny（一致性）

一致性的要求是指，對于任何客戶端（上圖Actor）來說，每次的讀操作，都能獲得最新的數(shù)據(jù)。即，當有客戶端向A節(jié)點寫入了新數(shù)據(jù)之后，其它客戶端從B節(jié)點中進行讀操作所獲得的數(shù)據(jù)必須也是最新的，是與A節(jié)點數(shù)據(jù)保持一致的。

Availability（可用性）

可用性的要求是指，每個請求都能在合理的時間內(nèi)獲得符合預(yù)期的響應(yīng)（不保證獲取的結(jié)果是最新的數(shù)據(jù)）。

按照上圖來看就是，客戶端只要向A節(jié)點或B節(jié)點發(fā)起請求后，只要這兩個節(jié)點收到了請求，就必須響應(yīng)給客戶端，但不需要保證響應(yīng)的值是否正確。

Partition tolerance（分區(qū)容錯性）

分區(qū)容錯性是指，當節(jié)點之間的網(wǎng)絡(luò)出現(xiàn)問題之后，系統(tǒng)依然能正常提供服務(wù)。

講完了C、A、P的含義和要求，我們繼續(xù)來看看它們之間如何組合使用。

二、CAP 怎么應(yīng)用？

先把視野回到這張圖上：

雖然我們知道有 CA、CP、AP 三種組合方式，但是在分布式系統(tǒng)的結(jié)構(gòu)下，網(wǎng)絡(luò)是不可能做到100%可靠的。既然網(wǎng)絡(luò)不能保證絕對可靠，那 P（分區(qū)容錯性）就是一個必選項了。原因如下：

如果選擇 CA組合，放棄 P（分區(qū)容錯性）。還是以最上面的圖中A和B節(jié)點來舉例，當發(fā)生節(jié)點間網(wǎng)絡(luò)故障時，為了保證 C（一致性），那么就必須將系統(tǒng)鎖住，不允許任何寫入操作，否者就會出現(xiàn)節(jié)點之間數(shù)據(jù)不一致了。但是鎖住了系統(tǒng)，就意味著當有寫請求進來的時候，系統(tǒng)是不可用的，這一點又違背了 A（可用性）原則。

因此分布式系統(tǒng)理論上是不可能有CA組合的，所以我們只能選擇 CP 和 AP組合架構(gòu)。

下面我們來詳細看一下 CP架構(gòu) 和 AP架構(gòu)的特點：

CP 架構(gòu)

CP架構(gòu)即 Consisteny（一致性）與 Partition tolerance（分區(qū)容錯性）的組合。

如上圖，由于網(wǎng)絡(luò)問題，節(jié)點A和節(jié)點B之前不能互相通訊。當有客戶端（上圖Actor）向節(jié)點A進行寫入請求時（準備寫入Message 2），節(jié)點A會不接收寫入操作，導(dǎo)致寫入失敗，這樣就保證了節(jié)點A和節(jié)點B的數(shù)據(jù)一致性，即保證了Consisteny（一致性）。

然后，如果有另一個客戶端（上圖另一個Actor）向B節(jié)點進行讀請求的時候，B請求返回的是網(wǎng)絡(luò)故障之前所保存的信息（Message 1），并且這個信息是與節(jié)點A一致的，是整個系統(tǒng)最后一次成功寫入的信息，是能正常提供服務(wù)的，即保證了Partition tolerance（分區(qū)容錯性）。

上述情況就是保障了CP架構(gòu)，但放棄了Availability（可用性）的方案。

AP 架構(gòu)

AP架構(gòu)即 Availability（可用性）與 Partition tolerance（分區(qū)容錯性）的組合架構(gòu)。

如上圖，由于網(wǎng)絡(luò)問題，節(jié)點A和節(jié)點B之前不能互相通訊。當有客戶端（上圖Actor）向節(jié)點A進行寫入請求時（準備寫入Message 2），節(jié)點A允許寫入，請求操作成功。但此時，由于A和B節(jié)點之前無法通訊，所以B節(jié)點的數(shù)據(jù)還是舊的（Message 1）。當有客戶端向B節(jié)點發(fā)起讀請求時候，讀到的數(shù)據(jù)是舊數(shù)據(jù)，與在A節(jié)點讀到的數(shù)據(jù)不一致。但由于系統(tǒng)能照常提供服務(wù)，所以滿足了Availability（可用性）要求。

因此，這種情況下，就是保障了AP架構(gòu)，但其放棄了 Consisteny（一致性）。

三、CAP 注意事項？

了解了CAP定理后，對于開發(fā)者而言，當我們構(gòu)建服務(wù)的時候，就需要根據(jù)業(yè)務(wù)特性作出權(quán)衡考慮，哪些點是當前系統(tǒng)可以取舍的，哪些是應(yīng)該重點保障的。

即使是在同一個系統(tǒng)中，不同模塊的數(shù)據(jù)可能應(yīng)用的CAP架構(gòu)都是不同的。舉個例子，在某個電商系統(tǒng)中，屬于用戶模塊的數(shù)據(jù)（賬密、錢包余額等）對一致性的要求很高，就可以采用CP架構(gòu)。而對于一些商品信息方面的數(shù)據(jù)對一致性要求沒那么高，但為了照顧用戶體驗，所以對可用性要求更高一些，那么這個模塊的數(shù)據(jù)就可以采用AP架構(gòu)。

另外，雖然上面第二節(jié)講到過我們只能選擇CP和AP，無法選擇CA。但這句話成立的前提條件是在系統(tǒng)發(fā)生了網(wǎng)絡(luò)故障的情況下。然而，網(wǎng)絡(luò)故障的概率在系統(tǒng)的整個生命周期中占比是很小的，因此我們在設(shè)計的時候，雖然要考慮網(wǎng)絡(luò)問題下的方案，但也要考慮網(wǎng)絡(luò)正常情況下的方案，即在網(wǎng)絡(luò)正常情況下，CA是可以實現(xiàn)的，我們也需要去保證在絕大多數(shù)時間下的CA架構(gòu)。

再者，即使我們按照CAP定理，三個中只能取其二，但不代表我們只需要保障其中的兩點，而完全的放棄第三點，我們應(yīng)該為不能保障的第三點也做一些防備措施或者冗余方案，來使系統(tǒng)更加的完善健全。

以上，就是對CAP定理的一些思考。