Kafka無法消費(fèi)?!我的分布式消息服務(wù)Kafka卻穩(wěn)如泰山！-創(chuàng)新互聯(lián)

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

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

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

Coordinator 為何物？ Coordinator 用于管理 Consumer Group 中各個(gè)成員，負(fù)責(zé)消費(fèi) offset 位移管理和 Consumer Rebalance 。 Consumer 在消費(fèi)時(shí)必須先確認(rèn) Consumer Group 對應(yīng)的 Coordinator ，隨后才能 join Group ，獲取對應(yīng)的 topic partition 進(jìn)行消費(fèi)。

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

1 、一個(gè) Consumer Group 對應(yīng)一個(gè) __consumers_offsets 的分區(qū)，首先先計(jì)算 Consumer Group 對應(yīng)的 __consumers_offsets 的分區(qū)，計(jì)算公式如下：

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

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

定位過程

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

不出所料， Coordinator 對應(yīng)分區(qū) Leader 為 -1 ，消費(fèi)端程序會(huì)一直等待，直到 Leader 選出來為止，這就直接導(dǎo)致了消費(fèi)卡死。

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

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

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

31 秒 847 的時(shí)候把 __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é)點(diǎn)是活的，日志如下 :

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

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

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

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

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

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

根因總結(jié)

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

問題總結(jié)

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

 

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

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

廣告

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