Kafka對reblance的優化，你瞭解嘛

本文分享自微信公衆號：WeCoding

本文概要

本文主要討論Kafka新版本reblance機制的優缺點，經過這篇文章，你能夠了解到如下內容：

1. 什麼是Reblance

2. Reblance過程

3. Kafka1.1對Reblance的優化
   

4. Kafka2.3對Reblance的優化

5. 新版本Reblance存在的問題

什麼是Reblance

• Reblance是Kafka協調者把partition分配給Consumer-group下每一個consumer實例的過程

• 在執行Reblance期間，Group內的全部Consumer沒法消費消息。所以頻繁的Reblance會下降消費系統的TPS。

一般在如下狀況，會出發Reblance：

• 組訂閱topic數變動

• topic partition數變動

• consumer成員變動

• consumer 加入羣組或者離開羣組的時候

• consumer被檢測爲崩潰的時候

Reblance過程

Kafka Reblance是經過協調者Coordnator實現的：

• consumer經過fetch線程拉消息（單線程）

• consumer經過心跳線程來與broker發送心跳。超時會認爲掛掉

• 每一個consumer group在broker上都有一個coordnator來管理，消費者加入和退

若是心跳線程在timeout時間內沒和broker發送心跳，coordnator會認爲該group應該進行reblance。接下來其餘consumer發來fetch請求後，coordnator將回復它們進行reblance準備。當consumer成員收到請求後，發送response給coordnator。其中只有leader的response中才包含分配策略。在consumer的下次請求到來時，coordnator會把分配策略同步給各consumer

存在的問題

在大型系統中，一個topic可能對應數百個consumer實例。這些consumer陸續加入到一個空消費組將致使屢次的rebalance；此外consumer 實例啓動的時間不可控，頗有可能超出coordinator肯定的rebalance timeout(即max.poll.interval.ms)，將會再次觸發rebalance，而每次rebalance的代價又至關地大，由於不少狀態都須要在rebalance前被持久化，而在rebalance後被從新初始化。

Kafka 1.1對reblance的優化

經過延遲進入PreparingRebalance狀態減小reblance次數

咱們系統的一個Group一般包含成百consumer，爲防止服務啓動時，這些consumer不斷加入引發頻繁的reblance，Kafka新增了延遲reblance機制。即從初始狀態到準備Reblance前，先進入InitialReblance狀態，等待一段時間(group.initial.rebalance.delay.ms)讓其餘consumer到來後再一塊兒執行reblance，從而下降其頻率。

Kafka2.3對reblance的優化

以上解決了服務啓動時，consumer陸續加入引發的頻繁Reblance，但對於運行過程當中，consumer超時或重啓引發的reblance則沒法避免，其中一個緣由就是，consumer重啓後，它的身份標識會變。簡單說就是Kafka不確認新加入的consumer是不是以前掛掉的那個。

在Kafka2.0中引入了靜態成員ID，使得consumer從新加入時，能夠保持舊的標識，這樣Kafka就知道以前掛掉的consumer又恢復了，從而不須要Reblance。這樣作的好處有兩個：

1. 下降了Kafka Reblance的頻率

2. 即便發生Reblance，Kafka儘可能讓其餘consumer保持原有的partition，減小了重分配引來的耗時、冪等等問題

新版reblance使用時存在的問題

目前系統把每一個上游的業務線抽象成一個topic，假設他們partition分別是十、20、40、80，咱們的80臺機器每每是分批次灰度發佈。這樣全量發佈完，只有80個partition的topic纔會被每臺機器所佔有，而其餘topic的partition只能被先啓動的那批consumer搶佔到，這樣就形成了分配不均勻；因爲粘性reblance的存在，下次reblance，大部分consumer依舊佔有以前partition，就形成了長久的分配不均勻。以前想過，配置每臺機器啓動那部分topic的consumer，但會強依賴IP，在容器化的趨勢下，顯然是不划算的。

長按訂閱更多精彩▼

若有收穫，點個在看，誠摯感謝