管理學(xué)上有一個(gè)木桶理論，一只水桶能裝多少水取決于它最短的那塊木板，這個(gè)理論推廣到分布式系統(tǒng)的可用性上，就是系統(tǒng)整體的可用性取決于系統(tǒng)中最容易出現(xiàn)故障，或者性能最低的組件。系統(tǒng)中的各個(gè)組件都要進(jìn)行高可用設(shè)計(jì)，防止單點(diǎn)故障，消息隊(duì)列也不例外，這一課時(shí)一起來(lái)看一下消息中間件的高可用設(shè)計(jì)。

消息隊(duì)列高可用手段

一般來(lái)說(shuō)，分布式系統(tǒng)的高可用依賴副本技術(shù)，副本的引入，使得分布式系統(tǒng)可以更好地進(jìn)行擴(kuò)展，當(dāng)出現(xiàn)某個(gè)節(jié)點(diǎn)宕機(jī)時(shí)，由于副本的存在，也能夠快速地進(jìn)行替換，提升系統(tǒng)整體可靠性，防止數(shù)據(jù)丟失。

消息隊(duì)列如何實(shí)現(xiàn)高可用的問題，如果出現(xiàn)在面試中，一般是作為一個(gè)相對(duì)開放的話題，你可以根據(jù)自己對(duì)分布式系統(tǒng)的了解，圍繞副本、集群、一致性等和面試官展開討論。消息隊(duì)列在系統(tǒng)中承擔(dān)了數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)傳輸?shù)膬煞N功能，所以消息隊(duì)列的高可用設(shè)計(jì)，也比數(shù)據(jù)庫(kù)、文件索引等持久性存儲(chǔ)要復(fù)雜。

下面的內(nèi)容，我以 Apache Kafka 為例，簡(jiǎn)單介紹一下消息隊(duì)列的高可用設(shè)計(jì)。

Kafka 的副本機(jī)制

Kafka 的高可用實(shí)現(xiàn)主要依賴副本機(jī)制，我把 Kakfa 的高可用，拆分成幾個(gè)小問題來(lái)講解，一來(lái)是為了更好地理解，二來(lái)很多細(xì)節(jié)問題也可能出現(xiàn)在面試中，方便你更好地掌握。

Broker 和 Partition 的關(guān)系

在分析副本機(jī)制之前，先來(lái)看一下 Broker 和 Partition 之間的關(guān)系。Broker 在英文中是代理、經(jīng)紀(jì)人的意思，對(duì)應(yīng)到 Kafka 集群中，是一個(gè) Kafka 服務(wù)器節(jié)點(diǎn)，Kafka 集群由多個(gè) Broker 組成，也就是對(duì)應(yīng)多個(gè) Kafka 節(jié)點(diǎn)。

Kafka 是典型的發(fā)布訂閱模式，存在 Topic 的概念，一個(gè) Broker 可以容納多個(gè) Topic，也就是一臺(tái)服務(wù)器可以傳輸多個(gè) Topic 數(shù)據(jù)。

不過 Topic 是一個(gè)邏輯概念，和物理上如何存儲(chǔ)無(wú)關(guān)，Kafka 為了實(shí)現(xiàn)可擴(kuò)展性，將一個(gè) Topic 分散到多個(gè) Partition 中，這里的 Partition 就是一個(gè)物理概念，對(duì)應(yīng)的是具體某個(gè) Broker 上的磁盤文件。

從 Partition 的角度，Kafka 保證消息在 Partition 內(nèi)部有序，所以 Partition 是一段連續(xù)的存儲(chǔ)，不能跨多個(gè) Broker 存在，如果是在同一個(gè) Broker 上，也不能掛載到多個(gè)磁盤。從 Broker 的角度，一個(gè) Broker 可以有多個(gè) Topic，對(duì)應(yīng)多個(gè) Partition。

除此之外，Partition 還可以細(xì)分為一個(gè)或者多個(gè) Segment，也就是數(shù)據(jù)塊，每個(gè) Segment 都對(duì)應(yīng)一個(gè) index 索引文件，以及一個(gè) log 數(shù)據(jù)文件。對(duì) Partition 的進(jìn)一步拆分，使得 Kafka 對(duì) 分區(qū)的管理更加靈活。

Replication 之間如何同步數(shù)據(jù)

基于 Kafka 的系統(tǒng)設(shè)計(jì)，你可以思考一下，如果沒有副本，那么當(dāng)某個(gè) Kafka Broker 掛掉，或者某臺(tái)服務(wù)器宕機(jī)（可能部署了多個(gè) Broker），存儲(chǔ)在其上的消息就不能被正常消費(fèi)，導(dǎo)致系統(tǒng)可用性降低，或者出現(xiàn)數(shù)據(jù)丟失，這不符合分布式高可用的要求，出現(xiàn)單點(diǎn)故障，也不滿足 Kafka 數(shù)據(jù)傳輸持久性和投遞語(yǔ)義的設(shè)計(jì)目標(biāo)。

Kafka 中有一個(gè)配置參數(shù) replication-factor（副本因子），可以調(diào)整對(duì)應(yīng)分區(qū)下副本的數(shù)量，注意副本因子數(shù)包含原來(lái)的 Partition，如果需要有 2 個(gè)副本，則要配置為 3。

假設(shè)現(xiàn)在有一個(gè)訂單的 Topic，配置分區(qū)數(shù)為 3，如果配置 replication-factor 為 3，那么對(duì)應(yīng)的有三個(gè)分區(qū)，每個(gè)分區(qū)都有 3 個(gè)副本，在有多個(gè)副本的情況下，不同副本之間如何分工呢？

每個(gè)分區(qū)下配置多個(gè)副本，多個(gè)副本之間為了協(xié)調(diào)，就必須有一定的同步機(jī)制。Kafka 中同一個(gè)分區(qū)下的不同副本，有不同的角色關(guān)系，分為 Leader Replication 和 Follower Replication。Leader 負(fù)責(zé)處理所有 Producer、Consumer 的請(qǐng)求，進(jìn)行讀寫處理，F(xiàn)ollower 作為數(shù)據(jù)備份，不處理來(lái)自客戶端的請(qǐng)求。

Follower 不接受讀寫請(qǐng)求，那么數(shù)據(jù)來(lái)自哪里呢？它會(huì)通過 Fetch Request 方式，拉取 Leader 副本的數(shù)據(jù)進(jìn)行同步。

Fetch 這個(gè)詞一般用于批量拉取場(chǎng)景，比如使用 Git 進(jìn)行版本管理的 fetch 命令，在 Kafka 中，會(huì)為數(shù)據(jù)同步開辟一個(gè)單獨(dú)的線程，稱為 ReplicaFetcherThread，該線程會(huì)主動(dòng)從 Leader 批量拉取數(shù)據(jù)，這樣可以高性能的實(shí)現(xiàn)數(shù)據(jù)同步。

Replication 分配有哪些約定

Kafka 中分區(qū)副本數(shù)的配置，既要考慮提高系統(tǒng)可用性，又要盡量減少機(jī)器資源浪費(fèi)。

一方面，為了更好地做負(fù)載均衡，Kafka 會(huì)將所有的 Partition 均勻地分配到整個(gè)集群上；另一方面，為了提高 Kafka 的系統(tǒng)容錯(cuò)能力，一個(gè) Partition 的副本，也要分散到不同的 Broker 上，否則就去了副本的意義。

一般來(lái)說(shuō)，為了盡可能地提升服務(wù)的可用性和容錯(cuò)率，Kafka 的分區(qū)和副本分配遵循如下的原則：

一個(gè) Topic 的 Partition 數(shù)量大于 Broker 的數(shù)量，使 Partition 盡量均勻分配到整個(gè)集群上；

同一個(gè)分區(qū)，所有的副本要盡量均勻分配到集群中的多臺(tái) Broker 上，盡可能保證同一個(gè) 分區(qū)下的主從副本，分配到不同的 Broker 上。

Leader Replication 如何選舉

一旦牽扯到數(shù)據(jù)同步，就必然會(huì)有 Leader 節(jié)點(diǎn)宕機(jī)以后重新選擇的問題。引入 Replication 機(jī)制之后，同一個(gè) Partition 可能會(huì)有多個(gè)副本，如果Leader掛掉，需要在這些副本之間選出一個(gè) 新的Leader。

Kafka 數(shù)據(jù)同步中有一個(gè) ISR（In-Sync Replicas，副本同步隊(duì)列）的概念，Leader 節(jié)點(diǎn)在返回 ACK 響應(yīng)時(shí)，會(huì)關(guān)注 ISR 中節(jié)點(diǎn)的同步狀態(tài)，所以這個(gè)隊(duì)列里的所有副本，都和 Leader 保持一致。

Kafka 的 ISR 依賴 ZooKeeper 進(jìn)行管理，ISR 副本同步隊(duì)列中的節(jié)點(diǎn)，擁有優(yōu)先選舉的權(quán)利，因?yàn)?ISR 里的節(jié)點(diǎn)和 Leader 保持一致，如果必須滿足一致性，只有 ISR 里的成員才能被選為 Leader。

如果某個(gè) Broker 掛掉，Kafka 會(huì)從 ISR 列表中選擇一個(gè)分區(qū)作為新的 Leader 副本。如果 ISR 列表是空的，這時(shí)候有兩個(gè)策略，一個(gè)是直接拋出 NoReplicaOnlineException 異常，保證一致性；另外一個(gè)是從其他副本中選擇一個(gè)作為 Leader，則可能會(huì)丟失數(shù)據(jù)，具體需要根據(jù)業(yè)務(wù)場(chǎng)景進(jìn)行配置。

所有的副本都掛了怎么辦

現(xiàn)在考慮一個(gè)極端情況，如果一個(gè)分區(qū)下的所有副本都掛掉了，那如何處理呢？在這種情況下，Kafka 需要等待某個(gè)副本恢復(fù)服務(wù)，具體可以有兩種方案：

• 等待 ISR 中的某個(gè)副本恢復(fù)正常，作為新的 Leader；

• 等待任一個(gè) 副本恢復(fù)正常，作為新的 Leader。

在第二種方案下，由于選擇的 Leader 節(jié)點(diǎn)可能不是來(lái)自 ISR，所以可能會(huì)存在數(shù)據(jù)丟失，不能保證已經(jīng)包含全部 Commit 的信息；如果選擇第一種方案，會(huì)保證數(shù)據(jù)不丟失，但是如果全部的 ISR 節(jié)點(diǎn)都徹底宕機(jī)，系統(tǒng)就無(wú)法對(duì)外提供服務(wù)了，對(duì)應(yīng)的分區(qū)會(huì)徹底不可用。

方案一優(yōu)先保證數(shù)據(jù)一致性，方案二優(yōu)先保證服務(wù)可用性，在實(shí)際配置中，可以根據(jù)不同的業(yè)務(wù)場(chǎng)景選擇不同的方案。

總結(jié)

這一課時(shí)分享了消息隊(duì)列高可用相關(guān)的知識(shí)，并且針對(duì) Kafka 的高可用實(shí)現(xiàn)，進(jìn)行了簡(jiǎn)單的分析。

實(shí)際上，Kafka 添加副本機(jī)制之后，需要解決的細(xì)節(jié)問題有很多。舉個(gè)例子，我們?cè)诘?29 課時(shí)講過消息投遞的不同語(yǔ)義，比如 At Most Once、At Least Once 等，當(dāng)添加了 Partition 之后，Kafka 需要保持投遞語(yǔ)義的完整，那么在生產(chǎn)者進(jìn)行投遞時(shí)，因?yàn)橐紤]不同副本的狀態(tài)，Leader 節(jié)點(diǎn)如何進(jìn)行 ACK 呢？很明顯，如果 Leader 節(jié)點(diǎn)等待所有的 Follower 節(jié)點(diǎn)同步后才返回 ACK，系統(tǒng)整體的性能和吞吐量會(huì)大幅降低，這也是 Kafka 引入 ISR 副本分層管理的原因之一。

除了 Kafka 以外，RocketMQ、RabbitMQ 等消息隊(duì)列又是怎么實(shí)現(xiàn)高可用的呢？感興趣的同學(xué)可以了解一下，歡迎留言分享。