聊聊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