聊聊kafka的group coordinator

序

本文主要來說一個kafka的group coordinator。在kafka0.9.0版本的時候，開始啓用了新的consumer config，這個新的consumer config採用bootstrap.servers替代以前版本的zookeeper.connect，主要是要漸漸弱化zk的依賴，把zk依賴隱藏到broker背後。

group coordinator

使用bootstrap.servers替代以前版本的zookeeper.connect，相關的有以下兩個改動：

• 在 Server 端增長了 GroupCoordinator 這個角色
• 將 topic 的 offset 信息由以前存儲在 zookeeper(/consumers/<group.id>/offsets/<topic>/<partitionId>,zk寫操做性能不高) 上改成存儲到一個特殊的 topic 中（__consumer_offsets）

從0.8.2版本開始Kafka開始支持將consumer的位移信息保存在Kafka內部的topic中（從0.9.0版本開始默認將offset存儲到系統topic中）

Coordinator通常指的是運行在broker上的group Coordinator，用於管理Consumer Group中各個成員，每一個KafkaServer都有一個GroupCoordinator實例，管理多個消費者組，主要用於offset位移管理和Consumer Rebalance。

rebalance時機

在以下條件下，partition要在consumer中從新分配：

• 條件1：有新的consumer加入
• 條件2：舊的consumer掛了
• 條件3：coordinator掛了，集羣選舉出新的coordinator
• 條件4：topic的partition新加
• 條件5：consumer調用unsubscrible()，取消topic的訂閱

__consumer_offsets

Consumer經過發送OffsetCommitRequest請求到指定broker（偏移量管理者）提交偏移量。這個請求中包含一系列分區以及在這些分區中的消費位置（偏移量）。偏移量管理者會追加鍵值（key－value）形式的消息到一個指定的topic（__consumer_offsets）。key是由consumerGroup-topic-partition組成的，而value是偏移量。

內存中也會維護一份最近的記錄，爲了在指定key的狀況下能快速的給出OffsetFetchRequests而不用掃描所有偏移量topic日誌。若是偏移量管理者因某種緣由失敗，新的broker將會成爲偏移量管理者而且經過掃描偏移量topic來從新生成偏移量緩存。

清除offset日誌

配置

log.cleaner.enable=true

compact

doc

• kafka-0.9-consumerconfigs
• Kafka-users About bootstrap.servers
• Kafka Detailed Consumer Coordinator Design
• Kafka Client-side Assignment Proposal
• Kafka源碼分析 Consumer(3) offset
• Kafka 之 Group 狀態變化分析及 Rebalance 過程
• kafka系列之(3)——Coordinator與offset管理和Consumer Rebalance
• Kafka 如何讀取offset topic內容 (__consumer_offsets)
• Committing and fetching consumer offsets in Kafka
• Kafka源碼深度解析－序列7 －Consumer －coordinator協議與heartbeat實現原理
• Kafka集羣磁盤使用率瞬超85%，幕後元兇竟是它？
• kafka 0.9.0.0 __consumer_offsets日誌清理問題？
• FusionInsight C60U10SPC002 Kafka磁盤容量不足告警
• 剖析Linkedln遭遇的Kafka「危機故障」
• Kafka 0.8.2 新的offset管理
• Consumer offset management in Kafka