問題要從一次Kafka的宕機(jī)開始說起。

筆者所在的是一家金融科技公司，但公司內(nèi)部并沒有采用在金融支付領(lǐng)域更為流行的 RabbitMQ ，而是采用了設(shè)計之初就為日志處理而生的 Kafka ，所以我一直很好奇Kafka的高可用實(shí)現(xiàn)和保障。從 Kafka 部署后，系統(tǒng)內(nèi)部使用的 Kafka 一直運(yùn)行穩(wěn)定，沒有出現(xiàn)不可用的情況。

但最近系統(tǒng)測試人員常反饋偶有Kafka消費(fèi)者收不到消息的情況，登陸管理界面發(fā)現(xiàn)三個節(jié)點(diǎn)中有一個節(jié)點(diǎn)宕機(jī)掛掉了。但是按照高可用的理念，三個節(jié)點(diǎn)還有兩個節(jié)點(diǎn)可用怎么就引起了整個集群的消費(fèi)者都接收不到消息呢？

要解決這個問題，就要從 Kafka 的高可用實(shí)現(xiàn)開始講起。

Kafka 的多副本冗余設(shè)計

不管是傳統(tǒng)的基于關(guān)系型數(shù)據(jù)庫設(shè)計的系統(tǒng)，還是分布式的如 zookeeper 、 redis 、 Kafka 、 HDFS 等等，實(shí)現(xiàn)高可用的辦法通常是采用冗余設(shè)計，通過冗余來解決節(jié)點(diǎn)宕機(jī)不可用問題。首先簡單了解 Kafka 的幾個概念：

邏輯模型

Broker （節(jié)點(diǎn)）：Kafka 服務(wù)節(jié)點(diǎn)，簡單來說一個 Broker 就是一臺 Kafka 服務(wù)器，一個物理節(jié)點(diǎn)。

Topic （主題）：在 Kafka 中消息以主題為單位進(jìn)行歸類，每個主題都有一個 Topic Name ，生產(chǎn)者根據(jù) Topic Name 將消息發(fā)送到特定的 Topic，消費(fèi)者則同樣根據(jù) Topic Name 從對應(yīng)的 Topic 進(jìn)行消費(fèi)。

Partition （分區(qū)）：Topic （主題）是消息歸類的一個單位，但每一個主題還能再細(xì)分為一個或多個 Partition （分區(qū)），一個分區(qū)只能屬于一個主題。主題和分區(qū)都是邏輯上的概念，舉個例子，消息1和消息2都發(fā)送到主題1，它們可能進(jìn)入同一個分區(qū)也可能進(jìn)入不同的分區(qū)（所以同一個主題下的不同分區(qū)包含的消息是不同的），之后便會發(fā)送到分區(qū)對應(yīng)的Broker節(jié)點(diǎn)上。

Offset （偏移量）：分區(qū)可以看作是一個只進(jìn)不出的隊列（Kafka只保證一個分區(qū)內(nèi)的消息是有序的），消息會往這個隊列的尾部追加，每個消息進(jìn)入分區(qū)后都會有一個偏移量，標(biāo)識該消息在該分區(qū)中的位置，消費(fèi)者要消費(fèi)該消息就是通過偏移量來識別。

就這么簡單？是的，基于上面這張多副本架構(gòu)圖就實(shí)現(xiàn)了 Kafka 的高可用。當(dāng)某個 Broker 掛掉了，甭?lián)?，這個 Broker 上的 Partition 在其他 Broker 節(jié)點(diǎn)上還有副本。你說如果掛掉的是 Leader 怎么辦？那就在 Follower中在選舉出一個 Leader 即可，生產(chǎn)者和消費(fèi)者又可以和新的 Leader 愉快地玩耍了，這就是高可用。

你可能還有疑問，那要多少個副本才算夠用？Follower 和 Leader 之間沒有完全同步怎么辦？一個節(jié)點(diǎn)宕機(jī)后 Leader 的選舉規(guī)則是什么？

直接拋結(jié)論：

多少個副本才算夠用？

副本肯定越多越能保證 Kafka 的高可用，但越多的副本意味著網(wǎng)絡(luò)、磁盤資源的消耗更多，性能會有所下降，通常來說副本數(shù)為3即可保證高可用，極端情況下將 replication-factor 參數(shù)調(diào)大即可。

Follower 和 Lead 之間沒有完全同步怎么辦？

Follower 和 Leader 之間并不是完全同步，但也不是完全異步，而是采用一種 ISR機(jī)制（ In-Sync Replica）。每個Leader會動態(tài)維護(hù)一個ISR列表，該列表里存儲的是和Leader基本同步的Follower。如果有 Follower 由于網(wǎng)絡(luò)、GC 等原因而沒有向 Leader 發(fā)起拉取數(shù)據(jù)請求，此時 Follower 相對于 Leader 是不同步的，則會被踢出 ISR 列表。所以說，ISR 列表中的 Follower 都是跟得上 Leader 的副本。

一個節(jié)點(diǎn)宕機(jī)后 Leader 的選舉規(guī)則是什么？

分布式相關(guān)的選舉規(guī)則有很多，像 Zookeeper的 Zab 、 Raft、 Viewstamped Replication、微軟的 PacificA 等。而 Kafka 的 Leader 選舉思路很簡單，基于我們上述提到的 ISR 列表，當(dāng)宕機(jī)后會從所有副本中順序查找，如果查找到的副本在ISR列表中，則當(dāng)選為Leader。另外還要保證前任Leader已經(jīng)是退位狀態(tài)了，否則會出現(xiàn)腦裂情況（有兩個Leader）。怎么保證？Kafka 通過設(shè)置了一個 controller 來保證只有一個 Leader。

Ack 參數(shù)決定了可靠程度

另外，這里補(bǔ)充一個面試考Kafka高可用必備知識點(diǎn)：request.required.asks 參數(shù)。

Asks 這個參數(shù)是生產(chǎn)者客戶端的重要配置，發(fā)送消息的時候就可設(shè)置這個參數(shù)。該參數(shù)有三個值可配置：0、1、All 。

第一種是設(shè)為0，意思是生產(chǎn)者把消息發(fā)送出去之后，之后這消息是死是活咱就不管了，有那么點(diǎn)發(fā)后即忘的意思，說出去的話就不負(fù)責(zé)了。不負(fù)責(zé)自然這消息就有可能丟失，那就把可用性也丟失了。

第二種是設(shè)為1，意思是生產(chǎn)者把消息發(fā)送出去之后，這消息只要順利傳達(dá)給了Leader，其他Follower有沒有同步就無所謂了。存在一種情況，Leader剛收到了消息，F(xiàn)ollower還沒來得及同步Broker就宕機(jī)了，但生產(chǎn)者已經(jīng)認(rèn)為消息發(fā)送成功了，那么此時消息就丟失了。

設(shè)為1是Kafka的默認(rèn)配置，可見Kafka的默認(rèn)配置也不是那么高可用，而是對高可用和高吞吐量做了權(quán)衡折中。

第三種是設(shè)為All（或者-1）

意思是生產(chǎn)者把消息發(fā)送出去之后，不僅Leader要接收到，ISR列表中的Follower也要同步到，生產(chǎn)者才會任務(wù)消息發(fā)送成功。

進(jìn)一步思考， Asks=All 就不會出現(xiàn)丟失消息的情況嗎？答案是否。當(dāng)ISR列表只剩Leader的情況下， Asks=All 相當(dāng)于 Asks=1 ，這種情況下如果節(jié)點(diǎn)宕機(jī)了，還能保證數(shù)據(jù)不丟失嗎？因此只有在 Asks=All 并且有ISR中有兩個副本的情況下才能保證數(shù)據(jù)不丟失。

解決問題

繞了一大圈，了解了Kafka的高可用機(jī)制，終于回到我們一開始的問題本身， Kafka 的一個節(jié)點(diǎn)宕機(jī)后為什么不可用？

我在開發(fā)測試環(huán)境配置的 Broker 節(jié)點(diǎn)數(shù)是3， Topic 是副本數(shù)為3， Partition 數(shù)為6， Asks 參數(shù)為1。

當(dāng)三個節(jié)點(diǎn)中某個節(jié)點(diǎn)宕機(jī)后，集群首先會怎么做？沒錯，正如我們上面所說的，集群發(fā)現(xiàn)有Partition的Leader失效了，這個時候就要從ISR列表中重新選舉Leader。如果ISR列表為空是不是就不可用了？并不會，而是從Partition存活的副本中選擇一個作為Leader，不過這就有潛在的數(shù)據(jù)丟失的隱患了。

所以，只要將Topic副本個數(shù)設(shè)置為和Broker個數(shù)一樣，Kafka的多副本冗余設(shè)計是可以保證高可用的，不會出現(xiàn)一宕機(jī)就不可用的情況（不過需要注意的是Kafka有一個保護(hù)策略，當(dāng)一半以上的節(jié)點(diǎn)不可用時Kafka就會停止）。那仔細(xì)一想，Kafka上是不是有副本個數(shù)為1的Topic？

問題出在了 __consumer_offset 上， __consumer_offset 是一個 Kafka 自動創(chuàng)建的 Topic，用來存儲消費(fèi)者消費(fèi)的 offset （偏移量）信息，默認(rèn) Partition 數(shù)為50。而就是這個Topic，它的默認(rèn)副本數(shù)為1。如果所有的 Partition 都存在于同一臺機(jī)器上，那就是很明顯的單點(diǎn)故障了！當(dāng)將存儲 __consumer_offset 的 Partition 的 Broker 給 Kill 后，會發(fā)現(xiàn)所有的消費(fèi)者都停止消費(fèi)了。這個問題怎么解決？

第一點(diǎn) ，需要將 __consumer_offset 刪除，注意這個Topic時Kafka內(nèi)置的Topic，無法用命令刪除，我是通過將 logs 刪了來實(shí)現(xiàn)刪除。

第二點(diǎn) ，需要通過設(shè)置 offsets.topic.replication.factor 為3來將 __consumer_offset 的副本數(shù)改為3。通過將 __consumer_offset 也做副本冗余后來解決某個節(jié)點(diǎn)宕機(jī)后消費(fèi)者的消費(fèi)問題。

最后，關(guān)于為什么 __consumer_offset 的 Partition 會出現(xiàn)只存儲在一個 Broker 上而不是分布在各個 Broker 上感到困惑。

作者：JanusWoo

來源：https://juejin.im/post/6874957625998606344

編輯：jq