為什么需要reblance
由于消費(fèi)者組訂閱了topic或悲，因topic partition數(shù)和消費(fèi)者組成員個數(shù)不同而存在的分配機(jī)制规辱。
什么情況下會reblance
- Topic partition發(fā)生變化曲稼。
- 訂閱的Topic個數(shù)發(fā)生變化。
- 消費(fèi)者組成員個數(shù)發(fā)生變化崔赌。新增成員或已有成員離開绷柒。
reblance的協(xié)調(diào)者
reblance過程需要Group Coordinator的參與。
Group Coordinator是一個服務(wù)突勇，每個Broker啟動的時候都會啟動一個該服務(wù)装盯。其作用是存儲Group的Meta信息坷虑，并負(fù)責(zé)存儲其訂閱的Topic的partition對應(yīng)offset信息。
partition的offset信息的存儲方式在Kafka不同版本中是不一樣的:
在0.9版本以前是存儲在ZK中的埂奈，存放路徑是
consumers/{group}/offsets/{topic}/{partition}迄损，其中ZK不適合頻繁的寫操作。在以后的版本中將Partition的Offset信息記錄到Kafka內(nèi)置Topic中账磺，Topic為
__consumer_offsets
上面描述了Group Coordinator的作用芹敌，那新消費(fèi)者組創(chuàng)建的時候是如何選擇自己的Group Coordinator的？
計算Group對應(yīng)在Topic
__consumer_offsets上的partition绑谣。-
根據(jù)Partition找到該P(yáng)artition的leader所對應(yīng)的Broker党窜，該Broker上的
Group Coordinator就是該Group的Coordinator。Group在
Topic__consumer_offsets上的對應(yīng)的partition的的計算算法是：// groupId是消費(fèi)者組的Id // groupMetadataTopicPartitionCount:是__consumer_offsets 的分區(qū)數(shù)借宵，默認(rèn)為50 partitionId=Math.abs(groupId.hashCode() % groupMetadataTopicPartitionCount)
如何reblance
reblance發(fā)生時幌衣，Group下的所有成員都會協(xié)調(diào)在一起共同參與，kafka能夠保證最大公平的分配壤玫。但是在reblance過程中豁护，Group下的所有成員實(shí)例都會停止消費(fèi)，直到reblance完成欲间。
reblance主要分為兩個操作楚里，加入組(join group)和組信息同步(sync group)。
-
加入組(join group)
這一步主要是該Group的所有成員向其
Group Coordinator發(fā)送JoinGroup請求猎贴，請求加入消費(fèi)者組班缎。一旦所有成員都發(fā)送了JoinGroup請求，Coordinator就會從所有消費(fèi)者組成員中選取一個作為leader她渴，并把組成員信息和訂閱信息也發(fā)給leader达址。 -
組信息同步(sync group)
這一步主要是leader分配消費(fèi)方案。完成分配后趁耗，會把分配方案封裝
syncGroup請求中發(fā)送給Coordinator沉唠，其中非leader也會發(fā)送syncGroup請求給Coordinator，只是請求信息為空苛败，Coordinator接收到syncGroup請求中的分配方案后满葛，會把方案作為syncGroup的響應(yīng)信息發(fā)送給各個成員。這樣每個組成員都知道自己該消費(fèi)那些分區(qū)了罢屈。
怎么避免無謂的reblance
由上可知能引起reblance無非下面三種情況：
- Topic partition發(fā)生變化嘀韧。
- 訂閱的Topic個數(shù)發(fā)生變化。
- 消費(fèi)者組成員個數(shù)發(fā)生變化儡遮。新增成員或已有成員離開乳蛾。
其中1和2我們可以人為或約定規(guī)范的方式來減少reblance的情況發(fā)生，但是3是引起reblance的最常見原因。
除了消費(fèi)者成員正常的添加和停止之外肃叶，還有些情況下Coordinator會錯誤的認(rèn)為消費(fèi)者組成員已停止而將其踢出組以致發(fā)生reblance蹂随。
在描述會發(fā)生上述誤reblance之前，先解釋下consumer端的幾個參數(shù)：
| key | 描述 |
|---|---|
| session.timeout.ms | 用來控制最大多長時間向coordinator發(fā)送自己活著的心跳不會被認(rèn)為超時因惭，默認(rèn)值1o秒 |
| heartbeat.interval.ms | 用來控制發(fā)送心跳請求頻率岳锁，值越小，發(fā)送心跳頻率會越高 |
| max.poll.interval.ms | 限定了 Consumer 端應(yīng)用程序兩次調(diào)用 poll 方法的最大時間間隔蹦魔。默認(rèn)值是 5分鐘 |
通過上述三個參數(shù)可知激率，引起誤reblance的有以下兩種情況：
超過
session.timeout.ms沒有及時發(fā)送心跳信息，導(dǎo)致組成員被踢出組勿决。消費(fèi)時間過長乒躺，超過
max.poll.interval.ms還沒有消費(fèi)完本次poll的所有消息，導(dǎo)致 Consumer 主動發(fā)起離開組的請求低缩。
