文章目錄

• 前言
• CAP理論
• • C consistency 一致性
  • A availability 可用性
  • P partition tolerance 分區(qū)容錯(cuò)性
• 一致性模型
• • 弱一致性
  • 強(qiáng)一致性
• 強(qiáng)一致性算法
• • 需要明確的問題
  • 強(qiáng)一致算法： 主從同步
  • 強(qiáng)一致性算法：多數(shù)派
  • 強(qiáng)一致算法：Paxos
  • • Basic Paxos
    • Multi Paxos
    • • 第一個(gè)版本：使用Proposer表示唯一的一個(gè)Leader
      • 第二個(gè)版本：將算法角色進(jìn)一步簡化
  • 強(qiáng)一致算法： Raft(基于log replicated的共識(shí)算法)
  • 強(qiáng)一致算法：ZAB
• 總結(jié)

前言

分布式系統(tǒng)是當(dāng)前互聯(lián)網(wǎng)領(lǐng)域的一個(gè)重要且大勢(shì)所趨的一種解決計(jì)算，存儲(chǔ)，網(wǎng)絡(luò)相關(guān)問題的方向，利用數(shù)量龐大的服務(wù)器節(jié)點(diǎn)作為底層，在其之上搭建一個(gè)可以跨省甚至跨國的龐大系統(tǒng)。

它能夠保證用戶數(shù)據(jù)的一致性，對(duì)用戶提供服務(wù)的高可用性，以及跨地域的分區(qū)容錯(cuò)性，而分布式一致性算法就是為了保證分布式系統(tǒng)能夠滿足其特性。

分布式一致性算法，我將其劃分到了分布式存儲(chǔ)技能樹中的分布式理論中：

本文的總結(jié)，將按照以下導(dǎo)圖進(jìn)行知識(shí)點(diǎn)的總結(jié)和梳理

CAP理論

提到分布式系統(tǒng)，那么CAP理論便無法繞過了。自從2000年，Eric Brewer教授提出了分布式系統(tǒng)設(shè)計(jì)一定會(huì)遵循：一致性，可用性，分區(qū)容錯(cuò)性的三個(gè)原則之后，互聯(lián)網(wǎng)界的分布式系統(tǒng)便都將其作為自己的衡量標(biāo)準(zhǔn)。后續(xù)的分布式系統(tǒng)設(shè)計(jì)也都按照CAP理論進(jìn)行設(shè)計(jì)，但是任何一個(gè)系統(tǒng)都只能在三個(gè)原則中滿足兩個(gè)，無法三個(gè)都滿足，即使像最近的亞馬遜S3和google spanner等全球分布式系統(tǒng)也只能滿足CP兩種，對(duì)于A則也只能提供多個(gè)9的可用性。

后續(xù)該理論上升為定理之后也有相關(guān)的證明論文，本節(jié)只是將其作為一個(gè)基本理論掃盲的介紹。

C consistency 一致性

在分布式系統(tǒng)中有多個(gè)節(jié)點(diǎn)，整個(gè)系統(tǒng)對(duì)外提供的服務(wù)應(yīng)該是一致的。即用戶在不同的系統(tǒng)節(jié)點(diǎn)訪問數(shù)據(jù)的時(shí)候應(yīng)該是同樣的結(jié)果，不能出現(xiàn)1號(hào)節(jié)點(diǎn)是結(jié)果1， 2號(hào)節(jié)點(diǎn)是結(jié)果2這種不一致的情況。

A availability 可用性

分布式系統(tǒng)為用戶提供服務(wù)，需要保證能夠在一些節(jié)點(diǎn)異常的情況下仍然支持為用戶提供服務(wù)。

P partition tolerance 分區(qū)容錯(cuò)性

分布式系統(tǒng)的部署可能跨省，甚至跨國。不同省份或者國家之間的服務(wù)器節(jié)點(diǎn)是通過網(wǎng)絡(luò)進(jìn)行連接，此時(shí)如果兩個(gè)地域之間的網(wǎng)絡(luò)連接斷開，整個(gè)分布式系統(tǒng)的體現(xiàn)就是分區(qū)容錯(cuò)性了。

在這種系統(tǒng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況下系統(tǒng)的服務(wù)就需要在一致性 和 可用性之間進(jìn)行取舍。

如果為了在出現(xiàn)網(wǎng)絡(luò)分區(qū)之后提供仍然能夠提供可用性，那么一致性必然無法滿足。因?yàn)榭捎眯缘囊笫窍到y(tǒng)仍然能夠提供服務(wù)，但是這個(gè)時(shí)候分布式系統(tǒng)在兩個(gè)地域之間無法通信，那么America的請(qǐng)求無法同步到China的服務(wù)節(jié)點(diǎn)上，整個(gè)系統(tǒng)的一致性顯然不能滿足。

同理 為了保證一致性，那么可用性也必然不能滿足，因?yàn)橐恢滦缘囊笫钦?qǐng)求A寫入America之后從China中讀，一定要能夠讀到這個(gè)請(qǐng)求（強(qiáng)一致性）或者 經(jīng)過一段時(shí)間之后也能夠讀到（弱一致性）。但是兩地域已經(jīng)出現(xiàn)了網(wǎng)絡(luò)分區(qū)，那么請(qǐng)求會(huì)阻塞從而降低可用性。

所以CAP理論一定是無法全部滿足三者，只能滿足其中的兩者。

一致性模型

弱一致性

弱一致性體現(xiàn)的是最終一致性，即如上CAP理論中 ，兩個(gè)地域的請(qǐng)求分別通過兩地的節(jié)點(diǎn)寫入，可以不用立即進(jìn)行同步，而是經(jīng)過一段時(shí)間之后兩地的用戶數(shù)據(jù)變?yōu)橐恢隆＿@種一致性成為弱一致性，即最終一致性。
也就是用戶一地寫入之后從另外一個(gè)節(jié)點(diǎn)讀取，無法立即讀到剛才寫入的數(shù)據(jù)。

比如DNS域名系統(tǒng)，Cassandra的 Gossip協(xié)議等都是最終一致性的體現(xiàn)。

全球目前的域名系統(tǒng)可以看作一個(gè)域名樹，由一個(gè)根域名節(jié)點(diǎn).cn下轄多個(gè).edu,.org,.com等子域名節(jié)點(diǎn)，而這一些子域名之下🈶?更多的子域名（以企業(yè)為例www.kuaishou.com，之下有多個(gè)數(shù)據(jù)中心，不同的數(shù)據(jù)中心又?jǐn)?shù)百上千的存儲(chǔ)節(jié)點(diǎn)），當(dāng)我們向某一個(gè)節(jié)點(diǎn)更新域名信息的時(shí)候，在其他節(jié)點(diǎn)立即訪問該記錄則不一定立即訪問到最終的更新，而是經(jīng)過一段時(shí)間之后我們能夠看到更新。

強(qiáng)一致性

強(qiáng)一致性是非常有必要的，比如業(yè)界的銀行系統(tǒng)，支付系統(tǒng)等對(duì)一致性要求非常高。
當(dāng)下比較流行的強(qiáng)一致性算法 像 Paxos,以及基于paxos衍生的raft,ZAB都能提供強(qiáng)一致性的能力。

強(qiáng)一致性描述的是一個(gè)請(qǐng)求在一個(gè)節(jié)點(diǎn)寫入之后在其他節(jié)點(diǎn)讀取，則該數(shù)據(jù)的更新能夠被讀到。
接下來主要描述的是一些強(qiáng)一致性算法的原理。

強(qiáng)一致性算法

需要明確的問題

• 數(shù)據(jù)不能存放在單個(gè)節(jié)點(diǎn)上，當(dāng)然這個(gè)是分布式系統(tǒng)的基礎(chǔ)形態(tài)，不滿足這個(gè)分布式系統(tǒng)也不能稱為分布式系統(tǒng)了
• 分布式系統(tǒng)對(duì)分區(qū)容錯(cuò)的方案是 state machine replication （復(fù)制狀態(tài)機(jī)），而強(qiáng)一致算法也被稱為共識(shí)算法(consensus)
  state狀態(tài)機(jī) 簡單來說就是一個(gè)函數(shù)，根據(jù)輸入的不同值來執(zhí)行對(duì)應(yīng)的請(qǐng)求處理邏輯。
  為了保證系統(tǒng)的最終一致性，不僅需要系統(tǒng)內(nèi)部達(dá)成共識(shí)，也需要一些client的行為。

強(qiáng)一致算法： 主從同步

主從同步復(fù)制：

1. master接受寫請(qǐng)求
2. master復(fù)制日志到slave
3. master等待直到所有從節(jié)點(diǎn)返回

這是一個(gè)強(qiáng)一致性算法的基礎(chǔ)，但是這樣的模型會(huì)出現(xiàn)如下問題：
比如一個(gè)slave節(jié)點(diǎn)異常宕機(jī)，那么master遲遲等不到該節(jié)點(diǎn)的返回，此時(shí)client請(qǐng)求便會(huì)阻塞。這樣的模型就是強(qiáng)一致模型，但是系統(tǒng)的可用性就會(huì)非常差，一個(gè)節(jié)點(diǎn)掛掉會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用。

強(qiáng)一致性算法：多數(shù)派

為了避免主從同步那樣一個(gè)節(jié)點(diǎn)異常，整個(gè)集群不可用的情況，推出了多數(shù)派。即每次寫入只需要保證寫入節(jié)點(diǎn)數(shù)大于N/2 個(gè)，讀節(jié)點(diǎn)數(shù)保證大于N/2個(gè)節(jié)點(diǎn)，此時(shí)即可認(rèn)為能夠向客戶端返回了。

這樣既能夠保證一致性，又提高了可用性。但是這個(gè)情況也只是針對(duì)單個(gè)請(qǐng)求寫入的情況下，而我們實(shí)際生產(chǎn)環(huán)境中會(huì)存在大量的并發(fā)場(chǎng)景。
比如：

并發(fā)這個(gè)分布式系統(tǒng)的不同節(jié)點(diǎn)執(zhí)行不同的操作，在滿足多數(shù)派的情況下可能會(huì)出現(xiàn)順序的問題，不同的節(jié)點(diǎn)因?yàn)檎?qǐng)求同步的時(shí)間問題可能出現(xiàn)請(qǐng)求的順序不一致。

強(qiáng)一致算法：Paxos

基礎(chǔ)的Paxos算法包括如下三種：

• Basic Paxos
• Multi Paxos
• Fast Paxos

paxos算法是Lasile Lamport的發(fā)明，這個(gè)算法已經(jīng)有很多論文對(duì)其基本原理進(jìn)行描述，因?yàn)楸旧斫巧芏嘤忠诓煌漠惓?chǎng)景下描述清楚，很難真正讓讀者對(duì)該算法融會(huì)貫通的。

Lamport為了更加形象的描述，提出了虛擬出來一個(gè)叫做Paxos的希臘城邦，這個(gè)城邦的管理者為了方便對(duì)民眾的管理，提出了一系列法案用來對(duì)民眾進(jìn)行約束，當(dāng)民眾有民事請(qǐng)求時(shí)，會(huì)提交民事訴訟給國會(huì)，有一個(gè)組織者將該訴訟整理成法案交給一個(gè)個(gè)議員進(jìn)行處理，議員之間又分為投票者和接受者用來實(shí)際進(jìn)行該法案最終是否要處理的決定，最終將結(jié)果反饋給組織者，由組織者將最終的結(jié)果再返還給民眾。

具體的角色如下：

• Client ：系統(tǒng)外部角色，請(qǐng)求的發(fā)起者。就像是故事中的民眾
• Proposer: 接受Client請(qǐng)求，想集群提出提議(propose)。并在投票的國會(huì)發(fā)生沖突的時(shí)候進(jìn)行調(diào)節(jié)，經(jīng)結(jié)果反饋給民眾
• Accpetor(Voter): 投票者，就是負(fù)責(zé)在集群內(nèi)部對(duì)法案是否要寫入進(jìn)行投票。只有滿足多數(shù)派(法定人數(shù)Quorum的由來)的情況下提議才會(huì)被接受，像是國會(huì)。
• Learner：接受者，即進(jìn)行backup,將民眾的請(qǐng)求記錄下來。這個(gè)角色對(duì)集群一致性本身并沒有什么影響。

Basic Paxos

主要分為如下幾個(gè)階段(phases):

1. Phase 1a： Prepare階段
   這個(gè)階段Proposer提出一個(gè)提案編號(hào)為N；此時(shí)N大于這個(gè)Proposer之前提出的議案，請(qǐng)求這個(gè)集群的Acceptor Quorum接受。
2. Phase 1b: Promise階段
   如果N大于此Acceptor之前接受的任何提案編號(hào)則接受，否則拒絕。
3. Phase 2a: Accept階段
   如果Acceptor內(nèi)部投票通過的人數(shù)達(dá)到了多數(shù)派，則Proposer會(huì)發(fā)出accept的請(qǐng)求，該請(qǐng)求包括提案編號(hào)為N，以及提案的內(nèi)容（用戶請(qǐng)求的內(nèi)容）
4. Phase2b: Accepted階段
   如果此acceptor在此期間沒有收到任何編號(hào)大于N的提案，則接受此提案內(nèi)容，否則忽略。接受之后會(huì)向Proposer返回成功，且將議案的內(nèi)容交給Learner進(jìn)行backup

正常的處理流程如下：

客戶端發(fā)起request請(qǐng)求到Proposer，然后Proposer發(fā)出提案并攜帶提案的編號(hào)1，分別發(fā)給每一個(gè)Acceptor；每一個(gè)Acceptor根據(jù)天都編號(hào)是否滿足大于1，將投票結(jié)果通過Propose階段反饋給Proposer；Proposer收到Acceptor的結(jié)果判斷是否達(dá)到了多數(shù)派，達(dá)到了多數(shù)派則向Acceptor發(fā)出Accept請(qǐng)求，并攜帶提案的具體內(nèi)容V；Acceptor收到提案內(nèi)容后向Proposer反饋Accepted表示收到，并將提案內(nèi)容交給Learner進(jìn)行備份。

Learner寫入提案內(nèi)容之后向Client發(fā)送完成請(qǐng)求的響應(yīng)。

當(dāng)Acceptor出現(xiàn)異常時(shí)流程如下：

雖然Accetor3 出現(xiàn)異常，沒有向Proposer反饋，但是Proposer此時(shí)收到的接受提案的反饋有2個(gè)Acceptor，仍然滿足多數(shù)派的情況，此時(shí)仍然能夠?qū)⑻岚竷?nèi)容繼續(xù)寫入的，所以后續(xù)的Accept的發(fā)送只需要發(fā)送給剩下的兩個(gè)Acceptor即可。

當(dāng)Proposer出現(xiàn)異常時(shí)的情況如下：

Proposer失敗的話表示收到Acceptor的Propose請(qǐng)求之后無法繼續(xù)發(fā)送Accept請(qǐng)求，這個(gè)時(shí)候集群會(huì)重新選出另一個(gè)新的能夠工作的Proposer，再從prepare階段開始處理，同時(shí)Prepare的提案版本號(hào)會(huì)增加一個(gè)，但是提案的內(nèi)容還是之前的內(nèi)容。

當(dāng)出現(xiàn)活鎖的情況：
簡化了如下處理流程，當(dāng)然其中的 Proposers和Acceptors 不只一個(gè)，是由多個(gè)組成的。

基本情況就是集群中有多個(gè)Propser，當(dāng)proposer1發(fā)送prepare版本為1并收到propose的時(shí)候節(jié)點(diǎn)發(fā)生了異常，集群切換到了新的proposer，并重新prepare 版本2，準(zhǔn)備好和版本1相同的內(nèi)容的提案。（因?yàn)閍cceptor處理的過程中發(fā)現(xiàn)更高版本的提案，會(huì)丟棄當(dāng)前的版本，轉(zhuǎn)向更高版本去處理）。

當(dāng)proposer2等待acceptor的propose返回時(shí)，proposer1有上線了，發(fā)現(xiàn)自己prepare(1)提案被打斷，此時(shí)又準(zhǔn)備了一個(gè)更高版本的prepare(3)提案，打斷了proposer2的2版本提案；當(dāng)proposer2發(fā)現(xiàn)自己的2號(hào)版本被打斷，又準(zhǔn)備了更高的4號(hào)版本，從而打斷了propose1的3號(hào)提案版本；依此下去，整個(gè)集群將會(huì)阻塞在相同的提案的不斷提交之中，這種情況就是集群出現(xiàn)了活鎖。

當(dāng)然也有較好的解決措施，比如：proposer1的上線之后 重新提交法案使用隨機(jī)時(shí)間機(jī)制，即隨機(jī)生成一個(gè)時(shí)間戳，在這段時(shí)間內(nèi)不向Acceptor發(fā)送消息；這樣proposer2的提案能夠被處理完成，這個(gè)時(shí)候proposer1再次提交新的提案。

綜上這一些基本異常情況來看，basic paxos還是能夠保證系統(tǒng)的一致性和可用性，共識(shí)算法還是能夠正常工作。
但是basic還是有一些缺點(diǎn)：

• 難實(shí)現(xiàn)
  有太多的角色需要實(shí)現(xiàn)
• 效率低(2輪 rpc)
  每一個(gè)請(qǐng)求需要proposer和acceptor 至少交互兩次才能完成請(qǐng)求的處理
• 活鎖

這個(gè)時(shí)候推出了Multi Paxos，其中的特色就是Leader概念，Leader是由唯一的Proposer表示，所有的請(qǐng)求都需要經(jīng)過這個(gè)Leader進(jìn)行轉(zhuǎn)發(fā)。

Multi Paxos

第一個(gè)版本：使用Proposer表示唯一的一個(gè)Leader

Proposer可以直接用來做提案是否被接受的決定，而不用所有的acceptor各自決定是否要接受提案。

正常處理流程如下：

• 處理第一個(gè)請(qǐng)求的時(shí)候因?yàn)樾枰x擇leader，所以還是會(huì)走2輪rpc,從prepare 到最后的Accepted。
• 從第二個(gè)請(qǐng)求開始，所有的請(qǐng)求只需要交給Proposer，Proposer即可完成是否接受請(qǐng)求的決定，一次Accept即可達(dá)成將請(qǐng)求寫入Learner的過程。

第二個(gè)版本：將算法角色進(jìn)一步簡化

這個(gè)簡化之后便更加接近我們實(shí)際的分布式系統(tǒng)的情況

當(dāng)然這個(gè)還是正常請(qǐng)求的處理流程，不過只會(huì)通過一輪Accept通信即可完成請(qǐng)求的處理。

ps：簡化后的集群第一個(gè)請(qǐng)求還是會(huì)走2輪rpc，為了從servers中選舉出一個(gè)leader，這個(gè)過程還是會(huì)從prepare開始到Accepted完成。

強(qiáng)一致算法： Raft(基于log replicated的共識(shí)算法)

raft是更為簡化的multi paxos（其實(shí)也就是上一個(gè)圖中的paxos）算法，相比于paxos的復(fù)雜實(shí)現(xiàn)來說角色更少，問題更加精簡。
rafti整體來說可以拆分成三個(gè)子問題來達(dá)成共識(shí)：

• Leader Election 如何選擇出leader
• Log Replication 如何將log復(fù)制到其他的節(jié)點(diǎn)
• Safety 保證復(fù)制之后集群的數(shù)據(jù)是一致的

重新定義了新的角色：

• Leader 一個(gè)集群只有一個(gè)leader
• Follower 一個(gè)服從leader決定的角色
• Cadidate follower發(fā)現(xiàn)集群沒有l(wèi)eader，會(huì)重新選舉leader，參與選舉的節(jié)點(diǎn)會(huì)變成candidate

除了以上的精簡之外，raft還提供了完善的社區(qū) 甚至 完整共識(shí)過程的可視化展示，這里可以通過原理動(dòng)畫展示 : http://thesecretlivesofdata.com/raft/ 瀏覽。

主體過程如下：

1. 三個(gè)基本的節(jié)點(diǎn)角色介紹一下
   

2. Leader Election的選舉過程
   初始所有節(jié)點(diǎn)都是follower狀態(tài)，當(dāng)開始選舉的時(shí)候?qū)⒋x舉節(jié)node a點(diǎn)置為candidate狀態(tài)
   canditdate會(huì)向其他的follower節(jié)點(diǎn)發(fā)送請(qǐng)求進(jìn)行l(wèi)eader投票，其他節(jié)點(diǎn)投票通過，則將candidate節(jié)點(diǎn)的狀態(tài)置為leader狀態(tài)。

接下來通過兩種心跳時(shí)間來詳細(xì)看一下選舉過程的實(shí)現(xiàn)
在leader election選舉的過程中會(huì)有兩種timeout的設(shè)置來控制整個(gè)的選舉過程：

• Election timeout
  表示follower等待請(qǐng)求的超時(shí)時(shí)間，如果這個(gè)時(shí)間結(jié)束前還沒有收到來自leader或者選舉leader的請(qǐng)求，那么當(dāng)前follower便會(huì)變?yōu)?candidate。 raft給的設(shè)定值一般在150ms-300ms之間的隨機(jī)值。
  變成candidate之后，當(dāng)前節(jié)點(diǎn)會(huì)立即發(fā)送leader的投票請(qǐng)求，其他的follower節(jié)點(diǎn)會(huì)重置選舉的超時(shí)時(shí)間。

• heartbeat timeout
  新選舉出來的leader每隔一段時(shí)間會(huì)發(fā)送一個(gè)請(qǐng)求給follower，這個(gè)時(shí)間就是心跳時(shí)間。
  同樣follower在相同的時(shí)間間隔內(nèi)回復(fù)leader一個(gè)請(qǐng)求，表示自己已經(jīng)收到。

  這樣的心跳間隔將會(huì)一直持續(xù)，直到一個(gè)follower停止接受心跳，變成candidate。

  重新選舉的過程就是candidate發(fā)送選舉請(qǐng)求，follower接受到之后返回對(duì)應(yīng)的心跳回應(yīng)，candidate根據(jù)心跳回應(yīng)的個(gè)數(shù)判斷是否滿足多數(shù)派，從而變成leader。變成leader之后，會(huì)持續(xù)發(fā)送心跳包來保證follower的存活。

3. Log Replication過程
   主要過程如下：
   客戶端發(fā)送請(qǐng)求到leader，leader接受之后將請(qǐng)求封裝成log entry，并將log副本發(fā)送給其他的follower節(jié)點(diǎn)。
   等待其他的follower節(jié)點(diǎn)回復(fù)，發(fā)現(xiàn)達(dá)到了多數(shù)派之后leader便將該entry寫入到自己的文件系統(tǒng)之中；
   寫入之后再發(fā)送請(qǐng)求，表示follower節(jié)點(diǎn)也可以寫入了。
   
   接下來我們?cè)敿?xì)看看log Replicated的實(shí)現(xiàn)過程，我們的leader被選舉出來之后用于請(qǐng)求的轉(zhuǎn)發(fā)，將接受到的用戶請(qǐng)求封裝成log entry，并將log entry的副本轉(zhuǎn)發(fā)給follower，這個(gè)log enry發(fā)送到follower之后也會(huì)用于重置follower的心跳時(shí)間。
   1. 客戶端會(huì)發(fā)送一條請(qǐng)求到leader，這個(gè)請(qǐng)求會(huì)追加到leader的log上，但此時(shí)還沒有寫入leader所在節(jié)點(diǎn)的文件系統(tǒng)之上
   2. 這個(gè)條leader的log 會(huì)在leader發(fā)送下一條心跳包的時(shí)候攜帶該請(qǐng)求的信息 一起發(fā)送給follower
   3. 當(dāng)entry提交到follower，且收到多數(shù)派的回復(fù)之后會(huì)給client一個(gè)回復(fù)，表示集群已經(jīng)寫入完成。同時(shí)將leader的log寫入自己的文件系統(tǒng)，并且發(fā)送command讓從節(jié)點(diǎn)也進(jìn)行寫入。這個(gè)過程就是multi paxos中的accepted階段。

關(guān)于raft更加詳細(xì)嚴(yán)謹(jǐn)?shù)募?xì)節(jié)介紹和性能測(cè)試 可以參考論文raft paper

強(qiáng)一致算法：ZAB

基本和raft相同，只是在一些名詞的叫法上有一些區(qū)別
比如ZAB 將某一個(gè)leader的周期稱為epoch,而raft稱為 term。

實(shí)現(xiàn)上的話 raft為了保證日志連續(xù)性，心跳方向是從leader到follower，ZAB則是相反的。

總結(jié)

本篇從理論和實(shí)現(xiàn)邏輯上描述了CAP理論、paxos相關(guān)的一致性算法變種以及基于multi paxos實(shí)現(xiàn)的簡化版強(qiáng)一致算法協(xié)議raft和ZAB，后續(xù)會(huì)從源碼層面一一觀察以及自實(shí)現(xiàn)基礎(chǔ)raft的通信來加深對(duì)分布式系統(tǒng)設(shè)計(jì)的理解。

可以看到分布式系統(tǒng)的核心算法還是圍繞CAP理論來進(jìn)行取舍，從系統(tǒng)前期的角色設(shè)計(jì)，到每個(gè)角色承擔(dān)的任務(wù)，到最后異常情況下的各個(gè)角色做出的反應(yīng)都能看到CAP的影子。這一些設(shè)計(jì)原則最終還是會(huì)反饋到用戶體驗(yàn)之上，雙十一的巨量流量，國外的APP群體和國內(nèi)實(shí)時(shí)通信交互，看似簡單的一個(gè)用戶功能背后的每一個(gè)RPC都是一段跨省，跨國的異地戀，即使異國之路被封鎖，合理的系統(tǒng)設(shè)計(jì)也能夠讓這段戀情持續(xù)。

各自安好，靜待他音。

想豬！！！

總結(jié)

以上是生活随笔為你收集整理的分布式一致性（共识）算法(Paxos,raft,ZAB)的一些总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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