序
本文主要来讲一个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
