從一次Kafka宕機，我明白了Kafka高可用原理

作者：佚名 2021-06-29 10:18:07

新聞

前端

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

專注于為中小企業(yè)提供成都網(wǎng)站設(shè)計、成都網(wǎng)站制作服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)芙蓉免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了近1000家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

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

筆者所在的是一家金融科技公司，但公司內(nèi)部并沒有采用在金融支付領(lǐng)域更為流行的 RabbitMQ ，而是采用了設(shè)計之初就為日志處理而生的 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 的多副本冗余設(shè)計

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

首先簡單了解 Kafka 的幾個概念：

邏輯模型

• Broker （節(jié)點）：Kafka 服務(wù)節(jié)點，簡單來說一個 Broker 就是一臺 Kafka 服務(wù)器，一個物理節(jié)點。
• Topic （主題）：在 Kafka 中消息以主題為單位進行歸類，每個主題都有一個 Topic Name ，生產(chǎn)者根據(jù) Topic Name 將消息發(fā)送到特定的 Topic，消費者則同樣根據(jù) Topic Name 從對應(yīng)的 Topic 進行消費。
• Partition （分區(qū)）：Topic （主題）是消息歸類的一個單位，但每一個主題還能再細分為一個或多個 Partition （分區(qū)），一個分區(qū)只能屬于一個主題。主題和分區(qū)都是邏輯上的概念，舉個例子，消息1和消息2都發(fā)送到主題1，它們可能進入同一個分區(qū)也可能進入不同的分區(qū)（所以同一個主題下的不同分區(qū)包含的消息是不同的），之后便會發(fā)送到分區(qū)對應(yīng)的Broker節(jié)點上。
• Offset （偏移量）：分區(qū)可以看作是一個只進不出的隊列（Kafka只保證一個分區(qū)內(nèi)的消息是有序的），消息會往這個隊列的尾部追加，每個消息進入分區(qū)后都會有一個偏移量，標識該消息在該分區(qū)中的位置，消費者要消費該消息就是通過偏移量來識別。

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

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

直接拋結(jié)論:

多少個副本才算夠用？

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

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

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

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

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

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

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

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

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

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

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

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

意思是生產(chǎn)者把消息發(fā)送出去之后，不僅Leader要接收到，ISR列表中的Follower也要同步到，生產(chǎn)者才會任務(wù)消息發(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ù)設(shè)置為和Broker個數(shù)一樣，Kafka的多副本冗余設(shè)計是可以保證高可用的，不會出現(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)刪除。

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

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

分享名稱：從一次Kafka宕機，我明白了Kafka高可用原理
文章網(wǎng)址：http://uogjgqi.cn/article/djsiidi.html