21天學(xué)會(huì)C語言？3天學(xué)會(huì)彈鋼琴？

放棄一切錯(cuò)誤方法，從今天開始“刻意練習(xí)”，

因?yàn)檫@才是最強(qiáng)大的，也是唯一正確的學(xué)習(xí)方法。

--《刻意練習(xí)》Anders Ericsson

引言

CAP問題已經(jīng)成了計(jì)算機(jī)科學(xué)中一個(gè)研究領(lǐng)域，之前說到分布式系統(tǒng)有哪些優(yōu)勢(shì)時(shí)講到三個(gè)提升：

1.系統(tǒng)可用性提升。

2.系統(tǒng)并發(fā)能力提升

3.系統(tǒng)容錯(cuò)能力提升。

那么這三方面在實(shí)施起來可以同時(shí)滿足嗎？答案是不能，設(shè)計(jì)分布式系統(tǒng)的時(shí)候，設(shè)計(jì)者需要理解一個(gè)重要的理論概念，CAP定理。

BASE: Basically Available（基本可用）, Soft state（軟狀態(tài)）和 Eventually consistent（最終一致性）

2012年Brewer發(fā)表了一篇文章，重新解釋了他對(duì)CAP定理的理解：

首先，網(wǎng)絡(luò)分區(qū)的發(fā)生是小概率事件，當(dāng)網(wǎng)絡(luò)沒有發(fā)生分區(qū)的時(shí)候沒有任何理由放棄C或者A

其次，在同一個(gè)系統(tǒng)中C和A的選擇可能發(fā)生多次，不同的子系統(tǒng)可以做不一樣的選擇，當(dāng)條件不同時(shí)做出的選擇可以不一樣，例如：不同的操作、數(shù)據(jù)、用戶可能會(huì)導(dǎo)致不同的選擇

最后，這三個(gè)屬性不是0和1的選擇，而是線性的。可用性很明顯可以從0%到100%，其實(shí)一致性甚至分區(qū)容忍性也是有差別的

CAP分別代表什么嗎？

關(guān)于CAP，它是2000 年 7 月，加州大學(xué)伯克利分校的 Eric Brewer 教授在 ACM PODC 會(huì)議上提出 CAP 猜想。2 年后，麻省理工學(xué)院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP。之后，CAP 理論正式成為分布式計(jì)算領(lǐng)域的公認(rèn)定理。

C的全拼是 Consistency，代表一致性的意思。

A的全拼是Availability，代表可用性的意思。

P的全拼是Partition tolerance，代表分區(qū)容錯(cuò)性的意思。

三選二：CP、AP、CA

一個(gè)分布式系統(tǒng)最多同時(shí)滿足一致性 (Consistency)，可用性 (Availability) 和分區(qū)容忍性 (Partition Tolerance) 這三項(xiàng)中的兩項(xiàng)。

• 同時(shí)滿足一致性（C）和可用性（A）就要犧牲掉容錯(cuò)性（P）

• 同時(shí)滿足可用性（A）和分區(qū)容錯(cuò)性（P）就要犧牲掉一致性（C）

• 同時(shí)滿足一致性（C）和分區(qū)容錯(cuò)性（P）就要犧牲掉可用性（A）

這三個(gè)象限，只能同時(shí)滿足其中兩個(gè)圓圈的交集。

舉個(gè)例子

用 Redis Cluster高可用架構(gòu)舉例：redis就能會(huì)將數(shù)據(jù)分片到多個(gè)實(shí)例(按照slot存儲(chǔ))中，即一個(gè)機(jī)房分擔(dān)一部分?jǐn)?shù)據(jù)。Master 負(fù)責(zé)寫，Master會(huì)自動(dòng)同步到 Slava。

Reids去中心集群架構(gòu)優(yōu)點(diǎn)：

無中心架構(gòu)：三機(jī)房部署，其中一主一從構(gòu)成一個(gè)分片，之間通過異步復(fù)制同步數(shù)據(jù)，異步復(fù)制存在數(shù)據(jù)不一致的時(shí)間窗口，保證高性能的同時(shí)犧牲了部分一致性一旦某個(gè)機(jī)房掉線，則分片上位于另一個(gè)機(jī)房的 slave 會(huì)被提升為 master 從而可以繼續(xù)提供服務(wù)，

可擴(kuò)展性：可線性擴(kuò)展到1000多個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)可動(dòng)態(tài)添加或刪除。

降低運(yùn)維成本，提高系統(tǒng)的擴(kuò)展性和可用性。

分析，這個(gè)分布式架構(gòu)中滿足了CAP中哪個(gè)兩個(gè)定理？

優(yōu)點(diǎn)1中講到，三機(jī)房部署，每個(gè)機(jī)房有一主一從，即一個(gè) Master 對(duì)應(yīng)一個(gè) Slave ，但是你會(huì)發(fā)現(xiàn)，機(jī)房1中的 Master 1 ?連接的 Slave 在機(jī)房2，機(jī)房2中的 Master 2 ?連接的 Slave 在機(jī)房3，機(jī)房3中的 Master 3 ?連接的 Slave 在機(jī)房1，這樣構(gòu)成一個(gè)環(huán)，為什么要這樣設(shè)計(jì)？

假設(shè)：機(jī)房斷電or火災(zāi)or其他各種原因，反正就是機(jī)房1所有機(jī)器都不能用了。

這個(gè)時(shí)候那機(jī)房1的全部數(shù)據(jù)都不能訪問了嗎？這顯然是我們不希望的。前面已經(jīng)說了Master 負(fù)責(zé)寫，Master會(huì)自動(dòng)同步到 Slava，如果 Master寫服務(wù)宕機(jī)，Slave 讀服務(wù)會(huì)被提升為 master ，也就是說機(jī)房1的數(shù)據(jù)在機(jī)房2的Slava2上還有備份，數(shù)據(jù)還在，在宕機(jī)的master沒有恢復(fù)前 Slave 要同時(shí)承擔(dān)讀寫服務(wù)，雖然累一點(diǎn)，但是還能用，這樣設(shè)計(jì)是為了提高可用性（A），和容錯(cuò)性（P）。系統(tǒng)準(zhǔn)許你一臺(tái)機(jī)器或者整個(gè)機(jī)房都宕機(jī)。系統(tǒng)仍然能。

公眾號(hào)【轉(zhuǎn)行程序員】回復(fù)”加群“，我會(huì)拉你進(jìn)技術(shù)群。

但是你會(huì)發(fā)現(xiàn)，單個(gè)機(jī)房如果距離很遠(yuǎn)， Master 1 ?的數(shù)據(jù)同步到 Slave2 上是跨機(jī)房，跨機(jī)房同步肯定不如同機(jī)房塊，這樣一來 Slave2 負(fù)責(zé)的讀就會(huì)有延遲，Master1 要更新的數(shù)據(jù)還沒有同步到他在另一個(gè)機(jī)房的備份前，讀操作就是不一致的，這樣設(shè)計(jì)顯然是犧牲掉一致性（C）。相信這樣分析應(yīng)該能理解CAP定理了。

進(jìn)一步分析：

讓同一組 Master - Slave 放在一個(gè)機(jī)房，同機(jī)房復(fù)制數(shù)據(jù)不是更快？這樣能不能解決數(shù)據(jù)一致（C）問題，答案是能，還有更好的解決一致性的辦法就是不要Master - Slave 組合，就一臺(tái)機(jī)器，一臺(tái)機(jī)器同時(shí)擔(dān)任讀寫請(qǐng)求，沒有延遲不存在數(shù)據(jù)一致性問題。這是時(shí)候如果宕機(jī)了怎么辦？這樣的架構(gòu)下，那就真的是不可用了，解決了一致性（C）卻犧牲了可用性（A）和容錯(cuò)性（P），太不劃算了。

總之，分布式系統(tǒng)下，CAP確實(shí)無法同時(shí)滿足，在Reids去中心集群架構(gòu)中，最優(yōu)的解決方案還是滿足可用性（A）和分區(qū)容錯(cuò)性（P）就要犧牲掉一致性（C），即使跨機(jī)房同步數(shù)據(jù)，延遲也不過1s，數(shù)據(jù)不一致的問題只出現(xiàn)在1s內(nèi)，日常開發(fā)中，很少遇到要求強(qiáng)一致性的場(chǎng)景。例如訂單系統(tǒng)，用戶更新了訂單支付狀態(tài)，讀訂單狀態(tài)是在從庫(kù)，有什么讀場(chǎng)景等不來這一秒？

如果真的必須要求強(qiáng)一致性，那可能就必須調(diào)整分布式架構(gòu)方案來。

總結(jié)

本文主要講解了CAP定理的概念，為什么要學(xué)習(xí)這個(gè)概念，設(shè)計(jì)高可用分布式系統(tǒng)時(shí)，你必須知道系統(tǒng)的短處，懂得CAP能讓你根據(jù)實(shí)際情況有舍有得。面試會(huì)被經(jīng)常問到，比如，你說你使用了消息隊(duì)列，解決了系統(tǒng)耦合問題，提高了響應(yīng)速度，那面試官問題：使用消息隊(duì)列有啥缺點(diǎn)？如果你知道CAP定理這個(gè)問題還難嗎？

顯然消息的延遲會(huì)帶來數(shù)據(jù)不一致問題。理想情況下消息不丟失那數(shù)據(jù)會(huì)最終一致，你能保證消息不丟失嗎？如何解決機(jī)問題，如果是我，我會(huì)選擇“最終一致性”，就是說不管消息延遲多久甚至丟失，設(shè)計(jì)一個(gè)離線定時(shí)任務(wù)，定期去掃描兩個(gè)系統(tǒng)的數(shù)據(jù)，有不一致的情況就主動(dòng)刷新同步，這樣保證最終一致。

參考資料

• CAP theorem – Wikipedia

• CAP Twelve Years Later: How the “Rules” Have Changed

聯(lián)系我

VX搜索【轉(zhuǎn)行程序員】回復(fù)”加群“，我會(huì)拉你進(jìn)技術(shù)群。講真的，在這個(gè)群，哪怕您不說話，光看聊天記錄也是一種成長(zhǎng)。阿里/騰訊/百度資深工程師、Google技術(shù)大神、IBM工程師、還有我王炸、敖丙、各路大牛都在，有任何不明白的都進(jìn)群提問。

最后，覺得王炸的文章不錯(cuò)就來個(gè)三連吧：關(guān)注 轉(zhuǎn)發(fā) 點(diǎn)贊

總結(jié)

以上是生活随笔為你收集整理的分布式系统不得不说的CAP定理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。