分布式系統(tǒng)

相信大家看過我的文章或者視頻的，都應(yīng)該知道什么是分布式系統(tǒng)，分布式系統(tǒng)就是一個(gè)系統(tǒng)由多個(gè)組成部分共同構(gòu)成，用戶的一個(gè)請(qǐng)求可能會(huì)經(jīng)過多個(gè)不同的計(jì)算機(jī)節(jié)點(diǎn)之后，通過運(yùn)算才會(huì)把結(jié)果響應(yīng)給用戶，那么這個(gè)請(qǐng)求所經(jīng)過的不同的幾個(gè)系統(tǒng)就是分布式系統(tǒng)。對(duì)于用戶來講，你是不是分布式系統(tǒng)，對(duì)他來講是透明的。參考如下圖：

-w520

圖中就表示一個(gè)用戶在經(jīng)歷下單過程會(huì)經(jīng)過多個(gè)系統(tǒng)，他們是分布式的，共同組成一個(gè)整體。

CAP 概念

在分布式系統(tǒng)中，必定會(huì)遇到CAP，如下：

• C（Consistency）：一致性

  • 在分布式系統(tǒng)中，所有的計(jì)算機(jī)節(jié)點(diǎn)的數(shù)據(jù)在同一時(shí)刻都是相同的，數(shù)據(jù)都是一致的。不能因?yàn)榉植际綄?dǎo)致不同系統(tǒng)拿到的數(shù)據(jù)不一致。也就是說，用戶在某一個(gè)節(jié)點(diǎn)寫了數(shù)據(jù)，在其他節(jié)點(diǎn)獲得該數(shù)據(jù)的值是最新的；如若是更新操作，那么所有用戶看到的也是更新后的新的值，不論哪個(gè)節(jié)點(diǎn)，不論集群，不論主備，獲得的數(shù)據(jù)都是相同的。

    • 如下圖：共有5個(gè)節(jié)點(diǎn)，往A節(jié)點(diǎn)去寫，那么其他節(jié)點(diǎn)的數(shù)據(jù)在同一時(shí)間都是相同的，其他用戶讀取的時(shí)候也都是相同的，數(shù)據(jù)的一致性很強(qiáng)。

      
      
      -w589

• A（Availability）：可用性

  • 保證你的系統(tǒng)可用，也就是說無論任何時(shí)候，系統(tǒng)都可以被用戶訪問到，用戶可以獲得正常的響應(yīng)結(jié)果。比如做好集群啊，做好主備啊等等，這個(gè)就是高可用。

    • 如下圖：集群是一個(gè)整體，不論是否有節(jié)點(diǎn)宕機(jī)，那么作為整體，他還是可以繼續(xù)對(duì)外提供服務(wù)的，保證了系統(tǒng)的可用性。

      
      
      -w585

• P（Partition tolerance）：分區(qū)容錯(cuò)性

  • 在整個(gè)分布式系統(tǒng)中，我們都是部署在不同的節(jié)點(diǎn)上，或者是不同的機(jī)房甚至是不同的地域，部署的時(shí)候會(huì)有一些子網(wǎng)，某一些服務(wù)會(huì)部署在不同的子網(wǎng)，每個(gè)子網(wǎng)就是一個(gè)區(qū)，也就是網(wǎng)絡(luò)分區(qū)，分區(qū)和分區(qū)之間的通信也有可能出現(xiàn)通信故障。某個(gè)節(jié)點(diǎn)或者網(wǎng)絡(luò)或者地域（分區(qū)）出現(xiàn)問題，整體整個(gè)系統(tǒng)還是照樣能夠提供一致性和可用性的服務(wù)。也就是說部分系統(tǒng)故障不會(huì)影響整體。為什么會(huì)這樣，主要是因?yàn)橛谐绦騜ug，計(jì)算機(jī)硬件問題，網(wǎng)絡(luò)問題，網(wǎng)線被挖斷了等等造成的綜合因素。所以呢，我們的訴求就是即使小部分出問題，也要保全整體。并且對(duì)于任何分布式系統(tǒng)來講，都需要去考慮分區(qū)容錯(cuò)的問題。

  • 附，以騰訊云為例，圖中就有兩處不同分區(qū)，第一個(gè)是在上海這個(gè)地域有不同的區(qū)域，不同區(qū)域通信走公網(wǎng)，可能有通信故障。其次就是私有網(wǎng)絡(luò)，也就是子網(wǎng)絡(luò)，他可以創(chuàng)建很多個(gè)，自己去定義不同的網(wǎng)段ip。

    
    
    -w458

CAP 無法同時(shí)滿足

如果從理論上來講，以上三點(diǎn)C/A/P都應(yīng)該滿足吧，但是系統(tǒng)是人開發(fā)的，那肯定會(huì)或多或少有各種各樣的問題。在分布式系統(tǒng)中同時(shí)滿足這三點(diǎn)是不可能的。所以對(duì)于CAP來講，只能滿足其中兩者，要么AP，要么CP，要么CA。如下圖：

-w589

為什么會(huì)這樣呢？我們舉一個(gè)例子，來看一下CAP能不能同時(shí)滿足，如下圖：

-w622

上圖中，ABCDE這5個(gè)節(jié)點(diǎn)都是分別部署在不同地域的機(jī)房的節(jié)點(diǎn)，假設(shè)現(xiàn)在我們的分區(qū)容錯(cuò)性P做的很好，保證不會(huì)出現(xiàn)網(wǎng)絡(luò)方面的故障，這個(gè)時(shí)候我們來看一下一致性C和可用性A?，F(xiàn)在有一個(gè)請(qǐng)求把數(shù)據(jù)寫入到了A節(jié)點(diǎn)，隨后用戶的下一個(gè)請(qǐng)求要訪問B節(jié)點(diǎn)，那么由于他們之間在不同的地域，數(shù)據(jù)同步需要有時(shí)間延遲，可能幾百毫秒可能1-2秒。那么讀請(qǐng)求要請(qǐng)求到一致的數(shù)據(jù)，就會(huì)被阻塞，阻塞的時(shí)候當(dāng)前這個(gè)系統(tǒng)就不可用了，因?yàn)閿?shù)據(jù)同步需要時(shí)間，所以此時(shí)的可用性A就無法滿足，只能滿足CP；那么再來看，假設(shè)要滿足系統(tǒng)可用性，那么請(qǐng)求讀到的數(shù)據(jù)，在節(jié)點(diǎn)同步的過程中就會(huì)是一個(gè)老的數(shù)據(jù)，數(shù)據(jù)就不能達(dá)到一致性C，所以這個(gè)時(shí)候就是AP。OK不？那么我們平時(shí)開發(fā)系統(tǒng)倒是在C和A之間取其一來搭配P的

組合搭配

那么 CP,AP,CA，這三種，哪個(gè)好呢？

• CP：滿足一致性和分區(qū)容錯(cuò)的系統(tǒng)，性能不會(huì)很高，因?yàn)橐恢滦允菚r(shí)時(shí)保持的。就比如說我提交一個(gè)訂單，這個(gè)訂單的數(shù)據(jù)要同步到各個(gè)系統(tǒng)，保證強(qiáng)一致性。那么這樣用戶請(qǐng)求大多都會(huì)被阻塞。需要耗時(shí)等待。redis，mongodb，hbase都是CP。（redis集群如果一個(gè)主節(jié)點(diǎn)掛了，那么slave成為master，他會(huì)有一個(gè)時(shí)間段導(dǎo)致不可用，A不滿足）
• CA：滿足一致性，滿足可用性，一般來說都是以單體存在的集群架構(gòu)，可擴(kuò)展性不高。一般都是關(guān)系型數(shù)據(jù)庫。
• AP：滿足可用性和分區(qū)容錯(cuò)，那么這樣就不是一致性了，往往會(huì)采用弱一致性，或者最終一致性。這也是通常用的最多的。 我們平時(shí)開發(fā)的系統(tǒng)就是以AP來展開工作的。

對(duì)于我們平時(shí)開發(fā)的時(shí)候，分區(qū)容錯(cuò)P是一定要滿足的，因?yàn)槲覀冊(cè)诓渴鸬臅r(shí)候往往都都是多節(jié)點(diǎn)集群部署，設(shè)置異地互備，比如北京機(jī)房和機(jī)房都提供服務(wù) ，所以，一定要容錯(cuò)。

那么接下來我們要抉擇一致性還是可用性呢？
一般來說，往往我們?cè)诖蠹揖W(wǎng)站架構(gòu)的時(shí)候，我們都會(huì)采用AP，主流的互聯(lián)網(wǎng)公司也是如此，也就是數(shù)據(jù)的弱一致性，因?yàn)橐ＷC系統(tǒng)的整體的高可用性以及容錯(cuò)性。啥叫弱一致性，比如我們經(jīng)?？搭^條，頭條的點(diǎn)贊數(shù)評(píng)論數(shù)或者微博粉絲數(shù)，具體的數(shù)值每個(gè)人瀏覽的時(shí)候可能不一樣，這個(gè)其實(shí)無所謂的，這就是弱一致性。而像Redis啊MongoDB這樣的中間件，是CP，也就是要保證數(shù)據(jù)的一致性，因?yàn)楫吘挂獮榫W(wǎng)站提供數(shù)據(jù)服務(wù)的，一致性必須滿足。

關(guān)于弱一致性

其實(shí)現(xiàn)在的互聯(lián)網(wǎng)環(huán)境里，很多項(xiàng)目都不會(huì)采用強(qiáng)一致性，因?yàn)楹茈y做，而往往采用弱一致性，因?yàn)橛脩艨梢越邮堋１热珉p11或者618的時(shí)候，訂單蹭蹭蹭的海量增加，我們只需要關(guān)注訂單下單成功就行，具體多少訂單，具體多少金額，我們不會(huì)去實(shí)時(shí)的統(tǒng)計(jì)計(jì)算的，因?yàn)闆]必要，會(huì)在高峰期過后逐步去統(tǒng)計(jì)，慢慢的實(shí)現(xiàn)一致性。那么這個(gè)就是目前主流的做法。

但是一定要注意，數(shù)據(jù)層面的交互，關(guān)系型數(shù)據(jù)庫，redis，mongodb等，他們肯定是強(qiáng)一致性，因?yàn)樾枰峁┙o你的網(wǎng)站數(shù)據(jù)服務(wù)。

其實(shí)呢，我們?cè)诨ヂ?lián)網(wǎng)環(huán)境里，往往會(huì)采用BASE理論，
Base = Basically Available Soft-state Eventually-Consistent
也就是達(dá)到基本可用軟狀態(tài)的最終一致性。它是比較平衡了CAP后得到的結(jié)論，這也是絕大多數(shù)互聯(lián)網(wǎng)系統(tǒng)實(shí)踐后的一個(gè)結(jié)果，他主要的核心思想就是忽略強(qiáng)一致性，使用弱一致性來達(dá)到最終一致。