Kafka無法消費?!我的分布式消息服務Kafka卻穩如泰山！

  在一個月黑風高的夜晚，突然收到現網生產環境 Kafka 消息積壓的告警，夢中驚醒啊，馬上起來排查日志。

問題現象：消費請求卡死在查找 Coordinator

Coordinator 為何物？ Coordinator 用于管理 Consumer Group 中各個成員，負責消費 offset 位移管理和 Consumer Rebalance 。 Consumer 在消費時必須先確認 Consumer Group 對應的 Coordinator ，隨后才能 join Group ，獲取對應的 topic partition 進行消費。

那如何確定 Consumer Group 的 Coordinator 呢？分兩步走：

1 、一個 Consumer Group 對應一個 __consumers_offsets 的分區，首先先計算 Consumer Group 對應的 __consumers_offsets 的分區，計算公式如下：

__consumers_offsets partition# = Math.abs(groupId.hashCode() % groupMetadataTopicPartitionCount ，其中 groupMetadataTopicPartitionCount 由 offsets.topic.num.partitions 指定。

2 、 1 中計算的該 partition 的 leader 所在的 broker 就是被選定的 Coordinator 。

定位過程

Coordinator 節點找到了，現在看看 Coordinator 是否有問題：

不出所料， Coordinator 對應分區 Leader 為 -1 ，消費端程序會一直等待，直到 Leader 選出來為止，這就直接導致了消費卡死。

為啥 Leader 無法選舉？ Leader 選舉是由 Controller 負責的。 Controller 節點負責管理整個集群中分區和副本的狀態，比如 partition 的 Leader 選舉， topic 創建，副本分配， partition 和 replica 擴容等。現在我們看看 Controller 的日志：

1.          6 月 10 日 15:48:30,006 秒 Broker 1 成為 controller

此時感知的節點為 1 和 2 ，節點 3 在 zk 讀不出來：

31 秒 847 的時候把 __consumer_offsets 的分區 3 的 Leader 選為 1 ， ISR 為 [1,2] ， leader_epoch 為 14 ：

再過 1 秒后才感知到 Controller 發生變化，自身清退

2.          Broker 2 在其后幾百毫秒后 (15:48:30,936) 也成為 Controller

但是 Broker2  是感知到 Broker 3 節點是活的，日志如下 :

注意這個時間點， Broker1 還沒在 zk 把 __consumer_offsets 的分區 3 的 Leader 從節點 3 改為 1 ，這樣 Broker 2 還認為 Broker 3 是 Leader ，并且 Broker 3 在它認為是活的，所以不需要重新選舉 Leader 。這樣一直保持了相當長的時間，即使 Broker 1 已經把這個分區的 Leader 切換了，它也不感知。

3.          Broker 2 在 12 號的 21:43:19 又感知 Broker 1 網絡中斷，并處理節點失敗事件：

因為 Broker 2 內存中認為 __consumer_offsets 分區 3 的 Leader 是 broker 3 ，所以不會觸發分區 3 的 Leader 切換。

Broker 2 但是在處理失敗的節點 Broker 1 時，會把副本從 ISR 列表中去掉，去掉前會讀一次 zk ，代碼如下：

但是發現 zk 中分區 3 的 Leader 已經變為 1 ， ISR 列表為 [1,2] ，當要去掉的節點 1 就是 Leader 的時候， Leader 就會變為 -1 ，  ISR 只有 [2] ，從日志也可以看到：

這樣分區 3  的 Leader 一直為 -1 ，直到有新的事件觸發節點 2 重新選舉才能恢復（例如重啟某個節點）。

根因總結

出現網絡異常后，由于新老 controller 之間感知的可用節點不同，導致新 controller 對某個分區的 Leader 在內存中的信息與 zk 記錄元數據的信息不一致，導致 controller 選舉流程出現錯誤，選不出 Leader 。   需要有新的選舉事件才能觸發 Leader 選出來，例如重啟。

問題總結

這是一個典型的由于網絡異常導致腦裂，進而出現了多個 Controller ，菊廠分布式消息服務 Kafka（ https://www.huaweicloud.com/product/dmskafka.html ） 經過電信級的可靠性驗證，已經完美解決了這些問題 。