如何解決Kafka突然宕機了

這篇文章主要介紹“如何解決Kafka突然宕機了”，在日常操作中，相信很多人在如何解決Kafka突然宕機了問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何解決Kafka突然宕機了”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Kafka 宕機引發的高可用問題

從 Kafka 部署后，系統內部使用的 Kafka 一直運行穩定，沒有出現不可用的情況。

但最近系統測試人員常反饋偶有 Kafka 消費者收不到消息的情況，登陸管理界面發現三個節點中有一個節點宕機掛掉了。

但是按照高可用的理念，三個節點還有兩個節點可用怎么就引起了整個集群的消費者都接收不到消息呢?

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

Kafka 的多副本冗余設計

不管是傳統的基于關系型數據庫設計的系統，還是分布式的如 Zookeeper、Redis、Kafka、HDFS  等等，實現高可用的辦法通常是采用冗余設計，通過冗余來解決節點宕機不可用問題。

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

物理模型，如下圖：

邏輯模型，如下圖：

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

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

Partition(分區)：Topic(主題)是消息歸類的一個單位，但每一個主題還能再細分為一個或多個  Partition(分區)，一個分區只能屬于一個主題。

主題和分區都是邏輯上的概念，舉個例子，消息 1 和消息 2 都發送到主題  1，它們可能進入同一個分區也可能進入不同的分區(所以同一個主題下的不同分區包含的消息是不同的)，之后便會發送到分區對應的 Broker 節點上。

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

其實，根據上述的幾個概念，是不是也多少猜到了 Kafka 的多副本冗余設計實現了?別急，咱繼續往下看。

在 Kafka 0.8 版本以前，是沒有多副本冗余機制的，一旦一個節點掛掉，那么這個節點上的所有 Partition 的數據就無法再被消費。這就等于發送到  Topic 的有一部分數據丟失了。

在 0.8 版本后引入副本記者則很好地解決宕機后數據丟失的問題。副本是以 Topic 中每個 Partition 的數據為單位，每個 Partition  的數據會同步到其他物理節點上，形成多個副本。

每個 Partition 的副本都包括一個 Leader 副本和多個 Follower 副本，Leader 由所有的副本共同選舉得出，其他副本則都為  Follower 副本。

在生產者寫或者消費者讀的時候，都只會與 Leader 打交道，在寫入數據后 Follower 就會來拉取數據進行數據同步。

就這么簡單?是的，基于上面這張多副本架構圖就實現了 Kafka 的高可用。

當某個 Broker 掛掉了，甭擔心，這個 Broker 上的 Partition 在其他 Broker 節點上還有副本。

你說如果掛掉的是 Leader 怎么辦?那就在 Follower 中在選舉出一個 Leader 即可，生產者和消費者又可以和新的 Leader  愉快地玩耍了，這就是高可用。

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

直接拋結論：多少個副本才算夠用?副本肯定越多越能保證 Kafka 的高可用，但越多的副本意味著網絡、磁盤資源的消耗更多，性能會有所下降。

通常來說副本數為 3 即可保證高可用，極端情況下將 replication-factor 參數調大即可。

Follower 和 Leader 之間沒有完全同步怎么辦?Follower 和 Leader 之間并不是完全同步，但也不是完全異步，而是采用一種 ISR  機制(In-Sync Replica)。

每個 Leader 會動態維護一個 ISR 列表，該列表里存儲的是和 Leader 基本同步的 Follower。

如果有 Follower 由于網絡、GC 等原因而沒有向 Leader 發起拉取數據請求，此時 Follower 相對于 Leader  是不同步的，則會被踢出 ISR 列表。

所以說，ISR 列表中的 Follower 都是跟得上 Leader 的副本。

一個節點宕機后 Leader 的選舉規則是什么?分布式相關的選舉規則有很多，像 Zookeeper 的 Zab、Raft、Viewstamped  Replication、微軟的 PacificA 等。

而 Kafka 的 Leader 選舉思路很簡單，基于我們上述提到的 ISR 列表，當宕機后會從所有副本中順序查找，如果查找到的副本在 ISR  列表中，則當選為 Leader。

另外還要保證前任 Leader 已經是退位狀態了，否則會出現腦裂情況(有兩個Leader)。

怎么保證?Kafka 通過設置了一個 Controller 來保證只有一個 Leader。

Ack 參數決定了可靠程度

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

Asks 這個參數是生產者客戶端的重要配置，發送消息的時候就可設置這個參數。

該參數有三個值可配置：

• 0

• 1

• All

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

第二種是設為 1，意思是生產者把消息發送出去之后，這消息只要順利傳達給了 Leader，其他 Follower 有沒有同步就無所謂了。

存在一種情況，Leader 剛收到了消息，Follower 還沒來得及同步 Broker  就宕機了，但生產者已經認為消息發送成功了，那么此時消息就丟失了。

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

第三種是設為 All(或者 -1)，意思是生產者把消息發送出去之后，不僅 Leader 要接收到，ISR 列表中的 Follower  也要同步到，生產者才會任務消息發送成功。

進一步思考，Asks=All 就不會出現丟失消息的情況嗎?答案是否。

當 ISR 列表只剩 Leader 的情況下，Asks=All 相當于 Asks=1，這種情況下如果節點宕機了，還能保證數據不丟失嗎?

因此只有在 Asks=All 并且有 ISR 中有兩個副本的情況下才能保證數據不丟失。

解決問題

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

我在開發測試環境配置的 Broker 節點數是 3，Topic 是副本數為 3，Partition 數為 6，Asks 參數為 1。

當三個節點中某個節點宕機后，集群首先會怎么做?沒錯，正如我們上面所說的，集群發現有 Partition 的 Leader 失效了，這個時候就要從 ISR  列表中重新選舉 Leader。

如果 ISR 列表為空是不是就不可用了?并不會，而是從 Partition 存活的副本中選擇一個作為  Leader，不過這就有潛在的數據丟失的隱患了。

所以，只要將 Topic 副本個數設置為和 Broker 個數一樣，Kafka  的多副本冗余設計是可以保證高可用的，不會出現一宕機就不可用的情況(不過需要注意的是 Kafka 有一個保護策略，當一半以上的節點不可用時 Kafka  就會停止)。

那仔細一想，Kafka 上是不是有副本個數為 1 的 Topic?

問題出在了 __consumer_offset 上，__consumer_offset 是一個 Kafka 自動創建的 Topic，用來存儲消費者消費的  Offset(偏移量)信息，默認 Partition 數為 50。

而就是這個 Topic，它的默認副本數為 1。如果所有的 Partition 都存在于同一臺機器上，那就是很明顯的單點故障了!

當將存儲 __consumer_offset 的 Partition 的 Broker 給 Kill 后，會發現所有的消費者都停止消費了。

這個問題怎么解決?

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

第二點，需要通過設置 offsets.topic.replication.factor 為 3 來將 __consumer_offset 的副本數改為 3。

通過將 __consumer_offset 也做副本冗余后來解決某個節點宕機后消費者的消費問題。

到此，關于“如何解決Kafka突然宕機了”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！