2019獨角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

互聯(lián)網(wǎng)發(fā)展到現(xiàn)在，由于數(shù)據(jù)量大、操作并發(fā)高等問題，大部分網(wǎng)站項目都采用分布式的架構(gòu)。而分布式系統(tǒng)最大的特點數(shù)據(jù)分散，在不同網(wǎng)絡(luò)節(jié)點在某些時刻（數(shù)據(jù)未同步完，數(shù)據(jù)丟失），數(shù)據(jù)會不一致。

在2000年，Eric Brewer教授在PODC的研討會上提出了一個猜想：一致性、可用性和分區(qū)容錯性三者無法在分布式系統(tǒng)中被同時滿足，并且最多只能滿足其中兩個！

在2002年，Lynch證明其猜想，上升為定理。被這就是大家所認知的CAP定理。

CAP是所有分布式數(shù)據(jù)庫的設(shè)計標(biāo)準(zhǔn)。例如Zookeeper、Redis、HBase等的設(shè)計都是基于CAP理論的。

CAP定義

所謂的CAP就是分布式系統(tǒng)的三個特性：

• Consistency，一致性。所有分布式節(jié)點的數(shù)據(jù)是否一致。
• Availability，可用性。在部分節(jié)點有問題的情況（數(shù)據(jù)不一致、節(jié)點故障）下，是否能繼續(xù)響應(yīng)服務(wù)（可用）。
• Partition tolerance，分區(qū)容錯性。允許在節(jié)點（分區(qū)）數(shù)據(jù)不一致的情況。

深入理解

有A、B、C三個分布式數(shù)據(jù)庫。

當(dāng)A、B、C的數(shù)據(jù)是完全相同，那么就符合定理中的Consistency（一致性）。

假如A的數(shù)據(jù)與B的數(shù)據(jù)不相同，但是整體的服務(wù)（包含A、B、C的整體）沒有宕機，依然可以對外系統(tǒng)服務(wù)，那么就符合定理中的Availability（可用性）。

分布式數(shù)據(jù)庫是沒有辦法百分百時刻保持各個節(jié)點數(shù)據(jù)一致的。假設(shè)一個用戶再A庫上更新了一條記錄，在更新完這一刻，A與B、C庫的數(shù)據(jù)是不一致的。這種情況在分布式數(shù)據(jù)庫上是必然存在的。這就是Partition tolerance（分區(qū)容錯性）

當(dāng)數(shù)據(jù)不一致的時候，必定是滿足分區(qū)容錯性，如果不滿足，那么這個就不是一個可靠的分布式系統(tǒng)。

然而在數(shù)據(jù)不一致的情況下，系統(tǒng)要么選擇優(yōu)先保持數(shù)據(jù)一致性，這樣的話。系統(tǒng)首先要做的是數(shù)據(jù)的同步操作，此時需要暫停系統(tǒng)的響應(yīng)。這就是滿足CP。

若系統(tǒng)優(yōu)先選擇可用性，那么在數(shù)據(jù)不一致的情況下，會在第一時間放棄一致性，讓整體系統(tǒng)依然能運轉(zhuǎn)工作。這就是AP。

所以，分布式系統(tǒng)在通常情況下，要不就滿足CP，要不就滿足AP。

那么有沒有滿足CA的呢？有，當(dāng)分布式節(jié)點為1的時候，不存在P，自然就會滿足CA了。

例子

上面說到，分區(qū)容錯性是分布式系統(tǒng)中必定要滿足的，需要權(quán)衡的是系統(tǒng)的一致性與可用性。那么常見的分布式系統(tǒng)是基于怎樣的權(quán)衡設(shè)計的。

• Zookeeper 保證CP。當(dāng)主節(jié)點故障的時候，Zookeeper會重新選主。此時Zookeeper是不可用的，需要等待選主結(jié)束才能重新提供注冊服務(wù)。顯然，Zookeeper在節(jié)點故障的時候，并沒有滿足可用性的特性。在網(wǎng)絡(luò)情況復(fù)雜的生產(chǎn)環(huán)境下，這樣的的情況出現(xiàn)的概率也是有的。一旦出現(xiàn)，如果依賴Zookeeper的部分會卡頓，在大型系統(tǒng)上，很容易引起系統(tǒng)的雪崩。這也是大型項目不選Zookeeper當(dāng)注冊中心的原因。
• Eureka 保證AP。在Eureka中，各個節(jié)點是平等的，它們相互注冊。掛掉幾個節(jié)點依然可以提供注冊服務(wù)的（可以配置成掛掉的比例），如果連接的Eureka發(fā)現(xiàn)不可用，會自動切換到其他可用的幾點上。另外，當(dāng)一個服務(wù)嘗試連接Eureka發(fā)現(xiàn)不可用的時候，切換到另外一個Eureka服務(wù)上，有可能由于故障節(jié)點未來得及同步最新配置，所以這個服務(wù)讀取的數(shù)據(jù)可能不是最新的。所以當(dāng)不要求強一致性的情況下，Eureka作為注冊中心更為可靠。
• Git 其實Git也是也是分布式數(shù)據(jù)庫。它保證的是CP。很容易猜想到，云端的Git倉庫于本地倉庫必定是要保證數(shù)據(jù)的一致性的，如果不一致會先讓數(shù)據(jù)一致再工作。當(dāng)你修改完本地代碼，想push代碼到Git倉庫上時，假如云端的HEAD與本地的HEAD不一致的時候，會先同步云端的HEAD到本地HEAD，再把本地的HEAD同步到云端。最終保證數(shù)據(jù)的一致性。

---

更多技術(shù)文章、精彩干貨，請關(guān)注
個人博客：zackku.com
公眾號：Zack說碼

轉(zhuǎn)載于:https://my.oschina.net/zackku/blog/2877970

總結(jié)

以上是生活随笔為你收集整理的浅谈分布式CAP定理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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