序
本文主要來講一個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
