問題要從一次Kafka的宕機開始說起。

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

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

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

Kafka 的多副本冗余設計

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

邏輯模型

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

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

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

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

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

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

直接拋結論：

多少個副本才算夠用？

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

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

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

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

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

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

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

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

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

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

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

第三種是設為All（或者-1）

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

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

解決問題

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

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

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

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

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

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

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

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

作者：JanusWoo

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

編輯：jq