在一個月黑風高的夜晚，突然收到現(xiàn)網(wǎng)生產(chǎn)環(huán)境 Kafka 消息積壓的告警，夢中驚醒啊，馬上起來排查日志。

站在用戶的角度思考問題，與客戶深入溝通，找到雞冠網(wǎng)站設(shè)計與雞冠網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名與空間、虛擬空間、企業(yè)郵箱。業(yè)務覆蓋雞冠地區(qū)。

問題現(xiàn)象：消費請求卡死在查找 Coordinator

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

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

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

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

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

定位過程

Coordinator 節(jié)點找到了，現(xiàn)在看看 Coordinator 是否有問題：

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

為啥 Leader 無法選舉？ Leader 選舉是由 Controller 負責的。 Controller 節(jié)點負責管理整個集群中分區(qū)和副本的狀態(tài)，比如 partition 的 Leader 選舉， topic 創(chuàng)建，副本分配， partition 和 replica 擴容等?，F(xiàn)在我們看看 Controller 的日志：

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

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

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

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

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

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

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

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

因為 Broker 2 內(nèi)存中認為 __consumer_offsets 分區(qū) 3 的 Leader 是 broker 3 ，所以不會觸發(fā)分區(qū) 3 的 Leader 切換。

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

但是發(fā)現(xiàn) zk 中分區(qū) 3 的 Leader 已經(jīng)變?yōu)? 1 ， ISR 列表為 [1,2] ，當要去掉的節(jié)點 1 就是 Leader 的時候， Leader 就會變?yōu)? -1 ，  ISR 只有 [2] ，從日志也可以看到：

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

根因總結(jié)

出現(xiàn)網(wǎng)絡異常后，由于新老 controller 之間感知的可用節(jié)點不同，導致新 controller 對某個分區(qū)的 Leader 在內(nèi)存中的信息與 zk 記錄元數(shù)據(jù)的信息不一致，導致 controller 選舉流程出現(xiàn)錯誤，選不出 Leader 。   需要有新的選舉事件才能觸發(fā) Leader 選出來，例如重啟。

問題總結(jié)

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

 

網(wǎng)站題目：Kafka無法消費?!我的分布式消息服務Kafka卻穩(wěn)如泰山！-創(chuàng)新互聯(lián)
標題路徑：http://aaarwkj.com/article8/dppgip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、App設(shè)計、動態(tài)網(wǎng)站、網(wǎng)站改版、靜態(tài)網(wǎng)站、全網(wǎng)營銷推廣

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)