消費者重新平衡決定哪個消費者負責某些主題的所有可用分區的哪個子集。 例如，您可能有一個包含20個分區和10個使用者的主題。 在重新平衡結束時，您可能希望每個使用者都從2個分區中讀取數據。 如果關閉了這些使用者中的10個，則可能會期望每個使用者在重新平衡完成后具有1個分區。 消費者重新平衡是可以由Kafka自動處理的動態分區分配。

組協調員是負責與消費者進行通信以實現消費者之間平衡的經紀人之一。在早期版本中，Zookeeper存儲了元數據詳細信息，但最新版本存儲在經紀人上。消費者協調員收到了所有消費者組消費者的心跳和輪詢，因此他了解每個消費者心跳和經理在分區上的偏移量。

小組組長：消費者組的一位消費者擔任小組組長，由小組協調員選出，負責代表小組中的所有消費者做出分區分配決定。

重新平衡方案：

消費者組訂閱任何主題

消費者實例無法使用session.heart.beat時間間隔發送心跳。

消費者的長時間流程超出了輪詢超時

消費群體中的消費者通過例外

添加了新分區。

擴大消費者規模。 添加了新使用者或手動刪除了現有使用者

消費者再平衡

消費者重新平衡是在消費者請求加入一個小組或離開一個小組時啟動的。 小組負責人從小組協調員那里收到所有活躍消費者的名單。 組負責人使用PartitionAssigner決定分配給每個使用者的分區。 一旦組長完成分區分配，它就會將分配列表發送給組協調器，組協調器將這些信息發送回所有使用者。 組僅將適用的分區發送給其使用者，而不發送其他使用者分配的分區。 只有組長知道所有使用者及其分配的分區。 重新平衡完成后，消費者開始將“心跳”發送到仍活躍的“組協調器”。 使用者向組協調器發送OffsetFetch請求，以獲取為其分配的分區的最后提交的偏移量。 消費者開始消費新分配分區的消息。

國家管理

重新平衡時，組協調器將其狀態設置為“重新平衡”，并等待所有消費者重新加入組。

當組開始重新平衡時，組協調器首先將其狀態切換為重新平衡，以便通知所有交互的使用者重新加入組。 重新平衡完成后，組協調器會創建新的ID，并通知所有消費者，然后該組繼續進行同步階段，在此階段，消費者發送同步請求，并等待直到組長完成生成新的分配分區。一旦消費者收到新的分配分區，他們便進入穩定階段。

靜態會員

您的重新平衡操作相當繁瑣，因為它需要停止所有使用者并等待獲取新分配的分區。 在每次重新平衡時，始終創建新一代id，這意味著刷新所有內容。 為了解決此開銷，Kafka 2.3+引入了靜態成員資格以減少不必要的重新平衡。 KIP-345

在靜態成員資格狀態下，消費者狀態將保持不變，在重新平衡狀態下，將應用相同的分配。 它使用新的group.instance.id來保留成員身份。 因此，即使在最壞的情況下，成員ID也會被改組以分配新分區，但相同的使用者實例ID仍將獲得相同的分區分配

instanceId: A, memberId: 1, assignment: {0, 1, 2} instanceId: B, memberId: 2, assignment: {3, 4, 5} instanceId: C, memberId: 3, assignment: {6, 7, 8}

重啟后：

instanceId: A, memberId: 4, assignment: {0, 1, 2} instanceId: B, memberId: 2, assignment: {3, 4, 5} instanceId: C, memberId: 3, assignment: {6, 7, 8}

參考：

https://www.confluent.io/blog/kafka-rebalance-protocol-static-membership

https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances

翻譯自: https://www.javacodegeeks.com/2020/06/apache-kafka-consumer-rebalance.html

總結

以上是生活随笔為你收集整理的Apache Kafka消费者再平衡的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。