序

本文主要講述2PC及3PC，以及Paxos以及Raft協(xié)議。

兩類(lèi)一致性(操作原子性與副本一致性)

• 2PC協(xié)議用于保證屬于多個(gè)數(shù)據(jù)分片上的操作的原子性。這些數(shù)據(jù)分片可能分布在不同的服務(wù)器上，2PC協(xié)議保證多臺(tái)服務(wù)器上的操作要么全部成功，要么全部失敗。

• Paxos協(xié)議用于保證同一個(gè)數(shù)據(jù)分片的多個(gè)副本之間的數(shù)據(jù)一致性。當(dāng)這些副本分布到不同的數(shù)據(jù)中心時(shí)，這個(gè)需求尤其強(qiáng)烈。

一、2PC（阻塞、數(shù)據(jù)不一致問(wèn)題、單點(diǎn)問(wèn)題）

Two-Phase?Commit，兩階段提交

1、階段一：提交事務(wù)請(qǐng)求（投票階段）

（1）事務(wù)詢(xún)問(wèn)

協(xié)調(diào)者向所有的參與者發(fā)送事務(wù)內(nèi)容，詢(xún)問(wèn)是否可以執(zhí)行事務(wù)提交操作，并開(kāi)始等待各參與者的響應(yīng)

（2）執(zhí)行事務(wù)

各參與者節(jié)點(diǎn)執(zhí)行事務(wù)操作，并將Undo和Redo信息計(jì)入事務(wù)日志中

（3）各參與者向協(xié)調(diào)者反饋事務(wù)詢(xún)問(wèn)的響應(yīng)

如果參與者成功執(zhí)行了事務(wù)操作，那么就反饋給協(xié)調(diào)者Yes響應(yīng)，表示事務(wù)可以執(zhí)行；如果參與者沒(méi)有成功執(zhí)行事務(wù)，那么就反饋給協(xié)調(diào)者No響應(yīng)，表示事務(wù)不可以執(zhí)行。

2、階段二：執(zhí)行事務(wù)提交（執(zhí)行階段）

（1）執(zhí)行事務(wù)提交

如果所有參與者的反饋都是Yes響應(yīng)，那么

• A、發(fā)送提交請(qǐng)求

  協(xié)調(diào)者向所有參與者節(jié)點(diǎn)發(fā)出Commit請(qǐng)求

• B、事務(wù)提交

  參與者接收到Commit請(qǐng)求后，會(huì)正式執(zhí)行事務(wù)提交操作，并在完成提交之后釋放在整個(gè)事務(wù)執(zhí)行期間占用的事務(wù)資源

• C、反饋事務(wù)提交結(jié)果

  參與者在完成事務(wù)提交之后，向協(xié)調(diào)者發(fā)送ACK信息

• D、完成事務(wù)

  協(xié)調(diào)者接收到所有參與者反饋的ACK消息后，完成事務(wù)

（2）中斷事務(wù)

任何一個(gè)參與者反饋了No響應(yīng)，或者在等待超時(shí)之后，協(xié)調(diào)者尚無(wú)法接收到所有參與者的反饋?lái)憫?yīng)，那么就會(huì)中斷事務(wù)。

• A、發(fā)送回滾請(qǐng)求

  協(xié)調(diào)者向所有參與者節(jié)點(diǎn)發(fā)出Rollback請(qǐng)求

• B、事務(wù)回滾

  參與者接收到rollback請(qǐng)求后，會(huì)利用其在階段一中記錄的Undo信息來(lái)執(zhí)行事務(wù)回滾操作，并在完成回滾之后釋放整個(gè)事務(wù)執(zhí)行期間占用的資源

• C、反饋事務(wù)回滾結(jié)果

  參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK信息

• D、中斷事務(wù)

  協(xié)調(diào)者接收到所有參與者反饋的ACK信息后，完成事務(wù)中斷

優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：原理簡(jiǎn)單、實(shí)現(xiàn)方便
缺點(diǎn)：同步阻塞、單點(diǎn)問(wèn)題、數(shù)據(jù)不一致、太過(guò)保守

• （1）同步阻塞
  同步阻塞會(huì)極大地限制分布式系統(tǒng)的性能。在二階段提交的執(zhí)行過(guò)程中，所有參與該事務(wù)操作的邏輯都處于阻塞狀態(tài)，各個(gè)參與者在等待其他參與者響應(yīng)的過(guò)程中，將無(wú)法進(jìn)行其他任何操作。

• （2）單點(diǎn)問(wèn)題
  一旦協(xié)調(diào)者出現(xiàn)問(wèn)題，那么整個(gè)二階段提交流程將無(wú)法運(yùn)轉(zhuǎn)，更為嚴(yán)重的是，如果是在階段二中出現(xiàn)問(wèn)題，那么其他參與者將會(huì)一直處于鎖定事務(wù)資源的狀態(tài)中，無(wú)法繼續(xù)完成事務(wù)操作。

• （3）數(shù)據(jù)不一致
  在階段二，當(dāng)協(xié)調(diào)者向所有參與者發(fā)送commit請(qǐng)求之后，發(fā)生了局部網(wǎng)絡(luò)異常或協(xié)調(diào)者在尚未發(fā)完commit請(qǐng)求之前自身發(fā)生了崩潰，導(dǎo)致最終只有部分參與者接收到了commit請(qǐng)求，于是這部分參與者執(zhí)行事務(wù)提交，而沒(méi)收到commit請(qǐng)求的參與者則無(wú)法進(jìn)行事務(wù)提交，于是整個(gè)分布式系統(tǒng)出現(xiàn)了數(shù)據(jù)不一致性現(xiàn)象。

• （4）太過(guò)保守
  如果參與者在與協(xié)調(diào)者通信期間出現(xiàn)故障，協(xié)調(diào)者只能靠超時(shí)機(jī)制來(lái)判斷是否需要中斷事務(wù)，這個(gè)策略比較保守，需要更為完善的容錯(cuò)機(jī)制，任意一個(gè)節(jié)點(diǎn)的失敗都會(huì)導(dǎo)致整個(gè)事務(wù)的失敗。

二、3PC（解決2PC的阻塞，但還是可能造成數(shù)據(jù)不一致）

Three-Phase Commit，三階段提交，分為CanCommit、PreCommit、do Commit三個(gè)階段。

為了避免在通知所有參與者提交事務(wù)時(shí)，其中一個(gè)參與者crash不一致時(shí)，就出現(xiàn)了三階段提交的方式。三階段提交在兩階段提交的基礎(chǔ)上增加了一個(gè)preCommit的過(guò)程，當(dāng)所有參與者收到preCommit后，并不執(zhí)行動(dòng)作，直到收到commit或超過(guò)一定時(shí)間后才完成操作。

1、階段一CanCommit

• （1）事務(wù)詢(xún)問(wèn)
  協(xié)調(diào)者向各參與者發(fā)送CanCommit的請(qǐng)求，詢(xún)問(wèn)是否可以執(zhí)行事務(wù)提交操作，并開(kāi)始等待各參與者的響應(yīng)

• （2）參與者向協(xié)調(diào)者反饋詢(xún)問(wèn)的響應(yīng)
  參與者收到CanCommit請(qǐng)求后，正常情況下，如果自身認(rèn)為可以順利執(zhí)行事務(wù)，那么會(huì)反饋Yes響應(yīng)，并進(jìn)入預(yù)備狀態(tài)，否則反饋No。

2、階段二PreCommit

（1）執(zhí)行事務(wù)預(yù)提交

如果協(xié)調(diào)者接收到各參與者反饋都是Yes，那么執(zhí)行事務(wù)預(yù)提交

• A、發(fā)送預(yù)提交請(qǐng)求
  協(xié)調(diào)者向各參與者發(fā)送preCommit請(qǐng)求，并進(jìn)入prepared階段

• B、事務(wù)預(yù)提交
  參與者接收到preCommit請(qǐng)求后，會(huì)執(zhí)行事務(wù)操作，并將Undo和Redo信息記錄到事務(wù)日記中

• C、各參與者向協(xié)調(diào)者反饋事務(wù)執(zhí)行的響應(yīng)
  如果各參與者都成功執(zhí)行了事務(wù)操作，那么反饋給協(xié)調(diào)者Ack響應(yīng)，同時(shí)等待最終指令，提交commit或者終止abort

（2）中斷事務(wù)

如果任何一個(gè)參與者向協(xié)調(diào)者反饋了No響應(yīng)，或者在等待超時(shí)后，協(xié)調(diào)者無(wú)法接收到所有參與者的反饋，那么就會(huì)中斷事務(wù)。

• A、發(fā)送中斷請(qǐng)求

  協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求

• B、中斷事務(wù)

  無(wú)論是收到來(lái)自協(xié)調(diào)者的abort請(qǐng)求，還是等待超時(shí)，參與者都中斷事務(wù)

3、階段三doCommit

（1）執(zhí)行提交

• A、發(fā)送提交請(qǐng)求
  假設(shè)協(xié)調(diào)者正常工作，接收到了所有參與者的ack響應(yīng)，那么它將從預(yù)提交階段進(jìn)入提交狀態(tài)，并向所有參與者發(fā)送doCommit請(qǐng)求

• B、事務(wù)提交
  參與者收到doCommit請(qǐng)求后，正式提交事務(wù)，并在完成事務(wù)提交后釋放占用的資源

• C、反饋事務(wù)提交結(jié)果
  參與者完成事務(wù)提交后，向協(xié)調(diào)者發(fā)送ACK信息

• D、完成事務(wù)
  協(xié)調(diào)者接收到所有參與者ack信息，完成事務(wù)

（2）中斷事務(wù)

假設(shè)協(xié)調(diào)者正常工作，并且有任一參與者反饋No，或者在等待超時(shí)后無(wú)法接收所有參與者的反饋，都會(huì)中斷事務(wù)

• A、發(fā)送中斷請(qǐng)求
  協(xié)調(diào)者向所有參與者節(jié)點(diǎn)發(fā)送abort請(qǐng)求

• B、事務(wù)回滾
  參與者接收到abort請(qǐng)求后，利用undo日志執(zhí)行事務(wù)回滾，并在完成事務(wù)回滾后釋放占用的資源

• C、反饋事務(wù)回滾結(jié)果
  參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ack信息

• D、中斷事務(wù)
  協(xié)調(diào)者接收到所有參與者反饋的ack信息后，中斷事務(wù)。

階段三可能出現(xiàn)的問(wèn)題：
協(xié)調(diào)者出現(xiàn)問(wèn)題、協(xié)調(diào)者與參與者之間網(wǎng)絡(luò)出現(xiàn)故障。不論出現(xiàn)哪種情況，最終都會(huì)導(dǎo)致參與者無(wú)法及時(shí)接收到來(lái)自協(xié)調(diào)者的doCommit或是abort請(qǐng)求，針對(duì)這種情況，參與者都會(huì)在等待超時(shí)后，繼續(xù)進(jìn)行事務(wù)提交（timeout后中斷事務(wù)）。

優(yōu)點(diǎn)：降低參與者阻塞范圍，并能夠在出現(xiàn)單點(diǎn)故障后繼續(xù)達(dá)成一致
缺點(diǎn)：引入preCommit階段，在這個(gè)階段如果出現(xiàn)網(wǎng)絡(luò)分區(qū)，協(xié)調(diào)者無(wú)法與參與者正常通信，參與者依然會(huì)進(jìn)行事務(wù)提交，造成數(shù)據(jù)不一致。

三、Paxos（解決單點(diǎn)問(wèn)題）

基于消息傳遞且具有高度容錯(cuò)性的一致性算法。Paxos算法要解決的問(wèn)題就是如何在可能發(fā)生幾起宕機(jī)或網(wǎng)絡(luò)異常的分布式系統(tǒng)中，快速且正確地在集群內(nèi)部對(duì)某個(gè)數(shù)據(jù)的值達(dá)成一致，并且保證不論發(fā)生以上任何異常，都不會(huì)破壞整個(gè)系統(tǒng)的一致性。

拜占庭問(wèn)題：消息不完整或者被篡改。Paxos在維持領(lǐng)導(dǎo)者選舉或者變量修改一致性上，采取一種類(lèi)似議會(huì)投票的過(guò)半同意機(jī)制，比如設(shè)定一個(gè)領(lǐng)導(dǎo)者，需要將此看做一個(gè)議案，征求過(guò)半同意，每個(gè)節(jié)點(diǎn)通過(guò)一個(gè)議案會(huì)有編號(hào)記錄，再次收到此領(lǐng)導(dǎo)者的不同人選，發(fā)現(xiàn)已經(jīng)有編號(hào)記錄便駁回，最后以多數(shù)通過(guò)的結(jié)果為準(zhǔn)。

我們舉個(gè)簡(jiǎn)單的例子，來(lái)闡述一下Paxos的基本思想：假設(shè)我們有5臺(tái)計(jì)算機(jī)A、B、C、D、E，每臺(tái)計(jì)算機(jī)保存著公司CEO的信息，現(xiàn)在CEO任期到了，需要進(jìn)行新一界選舉了。

A計(jì)算機(jī)發(fā)起一個(gè)選舉議案，提議CEO為“張三”，如果沒(méi)有其他候選人議案，也沒(méi)有網(wǎng)絡(luò)問(wèn)題，只要其中半數(shù)以上計(jì)算機(jī)收到并通過(guò)議案，那么最終“張三”當(dāng)選CEO。由于是分布式環(huán)境，并發(fā)請(qǐng)求、機(jī)器故障、網(wǎng)絡(luò)故障等問(wèn)題是常態(tài)，如果A和E同時(shí)提交選舉議案，A提名“張三”，E提名“李四”，那么肯定會(huì)涉及多計(jì)算機(jī)的一致性問(wèn)題了：假設(shè)A、B、C先收到A的議案，D、E先收到E的議案，那么A繼續(xù)提交給D時(shí)，D告訴它已經(jīng)先收到E的議案了，因此駁回了A的請(qǐng)求。同樣E繼續(xù)提交給A、B、C時(shí)也碰到相同的問(wèn)題。

我們可以通過(guò)“在每臺(tái)計(jì)算機(jī)同時(shí)接受議案提交時(shí)設(shè)置一個(gè)編號(hào)，編號(hào)先的通過(guò)，編號(hào)后的駁回”的方式來(lái)實(shí)現(xiàn)。議案提交上去后，發(fā)現(xiàn)A、B、C投票“張三”為CEO，D、E投票“李四”為CEO，少數(shù)服從多數(shù)，因此最后結(jié)果為“張三”當(dāng)選CEO。

如果是C計(jì)算機(jī)發(fā)生了網(wǎng)絡(luò)問(wèn)題或者故障，雙方投票相同，那么選舉無(wú)法完成。

如果C計(jì)算機(jī)發(fā)生了網(wǎng)絡(luò)問(wèn)題或者故障，A、B、D投票“張三”，E投票“李四”，那么結(jié)果為“張三”當(dāng)選，而C對(duì)于這些情況一無(wú)所知，但是當(dāng)C計(jì)算機(jī)恢復(fù)正常時(shí)，他會(huì)發(fā)起一個(gè)“詢(xún)問(wèn)誰(shuí)是CEO”的議案獲取最新信息。簡(jiǎn)言之，Paxos對(duì)每個(gè)節(jié)點(diǎn)的并發(fā)修改采取編號(hào)記錄的方式保持一致性，對(duì)多個(gè)節(jié)點(diǎn)的并發(fā)修改采取少數(shù)服從多數(shù)的方式保持一致性。Paxos有點(diǎn)類(lèi)似分布式二階段提交方式，但是又不同，二階段提交不能是多數(shù)節(jié)點(diǎn)同意，必須是全部同意。為了遵守過(guò)半節(jié)點(diǎn)同意的約束，Paxos算法往往要求節(jié)點(diǎn)總數(shù)為奇數(shù)。

Paxos 算法解決的問(wèn)題是在一個(gè)可能發(fā)生上述異常的分布式系統(tǒng)中如何就某個(gè)值達(dá)成一致，保證不論發(fā)生以上任何異常，都不會(huì)破壞決議的一致性。一個(gè)典型的場(chǎng)景是，在一個(gè)分布式數(shù)據(jù)庫(kù)系統(tǒng)中，如果各節(jié)點(diǎn)的初始狀態(tài)一致，每個(gè)節(jié)點(diǎn)都執(zhí)行相同的操作序列，那么他們最后能得到一個(gè)一致的狀態(tài)。為保證每個(gè)節(jié)點(diǎn)執(zhí)行相同的命令序列，需要在每一條指令上執(zhí)行一個(gè)「一致性算法」以保證每個(gè)節(jié)點(diǎn)看到的指令一致。一個(gè)通用的一致性算法可以應(yīng)用在許多場(chǎng)景中，是分布式計(jì)算中的重要問(wèn)題。從20世紀(jì)80年代起對(duì)于一致性算法的研究就沒(méi)有停止過(guò)。

簡(jiǎn)單說(shuō)來(lái)，Paxos的目的是讓整個(gè)集群的結(jié)點(diǎn)對(duì)某個(gè)值的變更達(dá)成一致。Paxos算法基本上來(lái)說(shuō)是個(gè)民主選舉的算法——大多數(shù)的決定會(huì)成個(gè)整個(gè)集群的統(tǒng)一決定。任何一個(gè)點(diǎn)都可以提出要修改某個(gè)數(shù)據(jù)的提案，是否通過(guò)這個(gè)提案取決于這個(gè)集群中是否有超過(guò)半數(shù)的結(jié)點(diǎn)同意（所以Paxos算法需要集群中的結(jié)點(diǎn)是單數(shù)）。

這個(gè)算法有兩個(gè)階段（假設(shè)這個(gè)有三個(gè)結(jié)點(diǎn)：A，B，C）：

第一階段：Prepare階段

A把申請(qǐng)修改的請(qǐng)求Prepare Request發(fā)給所有的結(jié)點(diǎn)A，B，C。注意，Paxos算法會(huì)有一個(gè)Sequence Number（你可以認(rèn)為是一個(gè)提案號(hào)，這個(gè)數(shù)不斷遞增，而且是唯一的，也就是說(shuō)A和B不可能有相同的提案號(hào)），這個(gè)提案號(hào)會(huì)和修改請(qǐng)求一同發(fā)出，任何結(jié)點(diǎn)在“Prepare階段”時(shí)都會(huì)拒絕其值小于當(dāng)前提案號(hào)的請(qǐng)求。所以，結(jié)點(diǎn)A在向所有結(jié)點(diǎn)申請(qǐng)修改請(qǐng)求的時(shí)候，需要帶一個(gè)提案號(hào)，越新的提案，這個(gè)提案號(hào)就越是是最大的。

如果接收結(jié)點(diǎn)收到的提案號(hào)n大于其它結(jié)點(diǎn)發(fā)過(guò)來(lái)的提案號(hào)，這個(gè)結(jié)點(diǎn)會(huì)回應(yīng)Yes（本結(jié)點(diǎn)上最新的被批準(zhǔn)提案號(hào)），并保證不接收其它<n的提案。這樣一來(lái)，結(jié)點(diǎn)上在Prepare階段里總是會(huì)對(duì)最新的提案做承諾。

優(yōu)化：在上述 prepare 過(guò)程中，如果任何一個(gè)結(jié)點(diǎn)發(fā)現(xiàn)存在一個(gè)更高編號(hào)的提案，則需要通知 提案人，提醒其中斷這次提案。

第二階段：Accept階段

如果提案者A收到了超過(guò)半數(shù)的結(jié)點(diǎn)返回的Yes，然后他就會(huì)向所有的結(jié)點(diǎn)發(fā)布Accept Request（同樣，需要帶上提案號(hào)n），如果沒(méi)有超過(guò)半數(shù)的話，那就返回失敗。

當(dāng)結(jié)點(diǎn)們收到了Accept Request后，如果對(duì)于接收的結(jié)點(diǎn)來(lái)說(shuō)，n是最大的了，那么，它就會(huì)通過(guò)request（修改這個(gè)值），如果發(fā)現(xiàn)自己有一個(gè)更大的提案號(hào)，那么，結(jié)點(diǎn)就會(huì)拒絕request（拒絕修改）。

我們可以看以，這似乎就是一個(gè)“兩段提交”的優(yōu)化。其實(shí)，2PC/3PC都是分布式一致性算法的殘次版本，Google Chubby的作者M(jìn)ike Burrows說(shuō)過(guò)這個(gè)世界上只有一種一致性算法，那就是Paxos，其它的算法都是殘次品。

我們還可以看到：對(duì)于同一個(gè)值的在不同結(jié)點(diǎn)的修改提案就算是在接收方被亂序收到也是沒(méi)有問(wèn)題的。

四、Raft協(xié)議(解決paxos的實(shí)現(xiàn)難度)

Paxos 相比 Raft 比較復(fù)雜和難以理解。角色扮演和流程比 Raft 都要啰嗦。比如 Agreement 這個(gè)流程，在 Paxos 里邊：Client 發(fā)起請(qǐng)求舉薦 Proposer 成為 Leader，Proposer 然后向全局 Acceptors 尋求確認(rèn)，Acceptors 全部同意 Proposer 后，Proposer 的 Leader 地位得已承認(rèn)，Acceptors 還得再向Learners 進(jìn)行全局廣播來(lái)同步。而在 Raft 里邊，只有 Follower/Candidate/Leader 三種角色，角色本身代表狀態(tài)，角色之間進(jìn)行狀態(tài)轉(zhuǎn)移是一件非常自由民主的事情。Raft雖然有角色之分但是是全民參與進(jìn)行選舉的模式；但是在Paxos里邊，感覺(jué)更像議員參政模式。

三個(gè)角色

follower、candidate、leader。
最開(kāi)始大家都是follower，當(dāng)follower監(jiān)聽(tīng)不到leader，就可以自己成為candidate，發(fā)起投票

leader選舉：timeout限制

選舉的timeout

follower成為candidate的超時(shí)時(shí)間，每個(gè)follower都在150ms and 300ms之間隨機(jī)，之后看誰(shuí)先timeout，誰(shuí)就先成為candidate，然后它會(huì)先投自己一票，再向其他節(jié)點(diǎn)發(fā)起投票邀請(qǐng)。
如果其他節(jié)點(diǎn)在這輪選舉還沒(méi)有投過(guò)票，那么就給candidate投票，然后重置自己的選舉timeout。
如果得到大多數(shù)的投票就成為leader，之后定期開(kāi)始向follower發(fā)送心跳。

如果兩個(gè)follower同時(shí)成為candidate的話，如果最后得到的票數(shù)相同，則等待其他follower的選擇timeout之后成為candidate，繼續(xù)開(kāi)始新一輪的選舉。

log復(fù)制

leader把變動(dòng)的log借助心跳同步給follower，過(guò)半回復(fù)之后才成功提交，之后再下一次心跳之后，follower也commit變動(dòng)，在自己的node上生效。

分裂之后，另一個(gè)分區(qū)的follower接受不到leader的timeout，然后會(huì)有一個(gè)先timeout，成為candidate，最后成為leader。
于是兩個(gè)分區(qū)就有了兩個(gè)leader。

當(dāng)客戶(hù)端有變動(dòng)時(shí)，其中的leader由于無(wú)法收到過(guò)半的提交，則保持未提交狀態(tài)。有的leader的修改，可以得到過(guò)半的提交，則可以修改生效。

當(dāng)分裂恢復(fù)之后，leader開(kāi)始對(duì)比選舉的term，發(fā)現(xiàn)有更高的term存在時(shí)，他們會(huì)撤銷(xiāo)未提交的修改，然后以最新的為準(zhǔn)。

五、ISR的機(jī)制(解決f容錯(cuò)的2f+1成本問(wèn)題)

Kafka并沒(méi)有使用Zab或Paxos協(xié)議的多數(shù)投票機(jī)制來(lái)保證主備數(shù)據(jù)的一致性，而是提出了ISR的機(jī)制（In-Sync Replicas）的機(jī)制來(lái)保證數(shù)據(jù)一致性。

ISR認(rèn)為對(duì)于2f+1個(gè)副本來(lái)說(shuō)，多數(shù)投票機(jī)制要求最多只能允許f個(gè)副本發(fā)生故障，如果要支持2個(gè)副本的容錯(cuò)，則需要至少維持5個(gè)副本，對(duì)于消息系統(tǒng)的場(chǎng)景來(lái)說(shuō)，效率太低。

ISR的運(yùn)行機(jī)制如下：將所有次級(jí)副本數(shù)據(jù)分到兩個(gè)集合，其中一個(gè)被稱(chēng)為ISR集合，這個(gè)集合備份數(shù)據(jù)的特點(diǎn)是即時(shí)和主副本數(shù)據(jù)保持一致，而另外一個(gè)集合的備份數(shù)據(jù)允許其消息隊(duì)列落后于主副本的數(shù)據(jù)。在做主備切換時(shí)，只允許從ISR集合中選擇主副本，只有ISR集合內(nèi)所有備份都寫(xiě)成功才能認(rèn)為這次寫(xiě)入操作成功。在具體實(shí)現(xiàn)時(shí)，kafka利用zookeeper來(lái)保持每個(gè)ISR集合的信息，當(dāng)ISR集合內(nèi)成員變化時(shí)，相關(guān)構(gòu)件也便于通知。通過(guò)這種方式，如果設(shè)定ISR集合大小為f+1，那么可以最多允許f個(gè)副本故障，而對(duì)于多數(shù)投票機(jī)制來(lái)說(shuō)，則需要2f+1個(gè)副本才能達(dá)到相同的容錯(cuò)性。

參考

• 分布式系統(tǒng)的Raft算法

• 英文動(dòng)畫(huà)演示Raft(推薦)

• paxos-by-example

• 為啥CoreOS沒(méi)用Paxos，重新搞了Raft？

總結(jié)

以上是生活随笔為你收集整理的2PC到3PC到Paxos到Raft到ISR的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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