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

創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司，提供網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)，網(wǎng)頁設(shè)計(jì)，建網(wǎng)站，PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);可快速的進(jìn)行網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展；專業(yè)做搜索引擎喜愛的網(wǎng)站，是專業(yè)的做網(wǎng)站團(tuán)隊(duì)，希望更多企業(yè)前來合作!

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

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

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

CAP定義

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

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

深入理解

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

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

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

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

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

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

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

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

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

例子

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

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

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