阅读目标#

前三篇已经依次建立了三层模型：

1
第一篇
2
Log → Partition → Offset → Consumer Position
3

4
第二篇
5
RecordBatch → LogSegment → Index → Broker Data Path
6

7
第三篇
8
KafkaProducer.send()
9
→ RecordAccumulator
10
→ Sender
11
→ NetworkClient
12
→ Partition Leader

第四篇把视角移动到消费端。

很多 Kafka 教程会把 Consumer 简化成：

1
while (true) {
2
    ConsumerRecords<String, String> records =
3
        consumer.poll(Duration.ofSeconds(1));
4

5
    for (ConsumerRecord<String, String> record : records) {
6
        handle(record);
7
    }
8
}

这段代码看起来只是一个循环，但 poll() 背后同时推进了多套状态：

1
Partition 数据获取
2
Consumer 本地缓存
3
反序列化与交付
4
Group Coordinator 查找
5
成员身份与存活
6
Partition Assignment
7
Rebalance Callback
8
Offset Fetch / Commit
9
Metadata 与网络 I/O

因此 Consumer 最难的部分不是“怎么拉消息”，而是：

Kafka 如何在一个动态变化的分布式成员集合中，持续维护 Partition 的唯一 Ownership，并把业务处理进度安全地映射为可恢复的 Offset。

完成本篇后，你应该能够：

• 解释为什么 Kafka Consumer 使用 Pull，而不是由 Broker 主动 Push；
• 说明一次 poll() 为什么不等于一次 FetchRequest；
• 画出 Consumer 的 Fetch、缓存、poll 与业务处理流水线；
• 区分 Record Offset、Consumer Position、Committed Offset、LSO、HW 与 LEO；
• 解释 subscribe() 与 assign() 的所有权模型差异；
• 解释同一 Consumer Group 内 Partition 与 Consumer 的分配约束；
• 从 Group ID 推导 Group Coordinator 与 __consumer_offsets 的职责；
• 画出 Classic Protocol 的 FindCoordinator → JoinGroup → SyncGroup 完整链；
• 解释 Range、RoundRobin、Sticky 与 CooperativeSticky 的不同权衡；
• 解释 Eager Rebalance 为什么会产生全组停顿；
• 说明 Kafka 4.x 新 Consumer Protocol 为什么不再依赖全局同步屏障；
• 区分 heartbeat.interval.ms、session.timeout.ms 与 max.poll.interval.ms；
• 解释为什么 Heartbeat 正常仍可能发生 Livelock；
• 正确设计手动 Offset Commit，避免提交过早或提交乱序；
• 根据 Consumer Metrics 和 Group 状态定位 Lag 与 Rebalance Storm；
• 沿 Classic Consumer 与 Async Consumer 两条源码路线继续深入。

本文以 Apache Kafka 4.3.x 官方文档与 Java Client API 为主线。Kafka 4.0 起，KIP-848 新 Consumer Rebalance Protocol 已经 GA，但客户端默认仍是 group.protocol=classic；使用新协议需要显式设置 group.protocol=consumer。新协议采用 Broker 驱动的分配和 Fully Incremental Reconciliation，并使用改进后的 Consumer 线程模型。1

0.1 一个调用包含三类职责#

可以把 Consumer 工作拆成三条互相耦合但不同的链。

1
FetchRequest
2
    ↓
3
Broker Partition Leader
4
    ↓
5
FetchResponse
6
    ↓
7
Completed Fetch / Local Buffer
8
    ↓
9
Deserialize
10
    ↓
11
ConsumerRecords

1
FindCoordinator
2
    ↓
3
Join / Heartbeat
4
    ↓
5
Member Identity
6
    ↓
7
Session Liveness

1
Subscription
2
    ↓
3
Assignment Calculation
4
    ↓
5
Partition Revocation / Assignment
6
    ↓
7
Reconciliation

1.1 KafkaConsumer 不是线程安全的#

Kafka 官方 Javadoc 明确说明：

1
KafkaConsumer is NOT thread-safe

除 wakeup() 之外，不应该让多个线程无同步地调用同一个 Consumer。3

典型正确模型是：

1
一个 Consumer
2
        ↓
3
一个 Poll Thread
4
        ↓
5
顺序调用 Consumer API

关闭时，其他线程可以：

1
consumer.wakeup();

使正在阻塞的操作抛出 WakeupException，从而让 Poll Thread 进入退出逻辑。

不要把 Producer 的经验直接复制到 Consumer：

1
KafkaProducer
2
→ 线程安全，适合多个业务线程共享
3

4
KafkaConsumer
5
→ 非线程安全，Ownership、Position 与 Callback
6
   都依赖单一应用线程顺序

1.2 为什么 Consumer 比 Producer 更依赖线程约束#

Consumer 内部维护大量与调用顺序相关的状态：

1
当前 Subscription
2
当前 Assignment
3
每个 Partition 的 Position
4
Pause 状态
5
Pending Commit
6
Rebalance Callback
7
本地 Fetch Buffer
8
Group Member / Epoch

例如：

1
consumer.seek(tp, 100);
2
consumer.pause(Set.of(tp));
3
consumer.commitSync();

这些操作不是无状态 RPC，而是在修改同一个消费状态机。

如果多个线程同时调用：

1
线程 A：poll()
2
线程 B：seek()
3
线程 C：commit()

应用很难定义可靠的先后语义。

1.3 Classic 与 Consumer 两种内部 Runtime#

Kafka 4.x 的同一个 KafkaConsumer API，可以运行在两种 Group Protocol 下。

1
group.protocol=classic

1
Application Thread
2
    ↓
3
ClassicKafkaConsumer
4
    ↓
5
ConsumerCoordinator / SubscriptionState / Fetch
6
    ↓
7
ConsumerNetworkClient
8
    ↓
9
Broker
10

11
Heartbeat Thread
12
    ↓
13
Group Coordinator

1
group.protocol=consumer

1
Application Thread
2
    ↓
3
AsyncKafkaConsumer
4
    ↓
5
Application Event Queue
6

7
================ Thread Boundary ================
8

9
ConsumerNetworkThread
10
    ├── HeartbeatRequestManager
11
    ├── ConsumerMembershipManager
12
    ├── CommitRequestManager
13
    ├── FetchRequestManager
14
    └── NetworkClientDelegate

1.4 线程模型改变了什么#

新线程模型的目标之一，是减少：

1
网络协调进度
2
对应用 poll 调用节奏的直接依赖

但业务处理仍必须尊重：

1
max.poll.interval.ms

因为 Kafka 不只关心“进程是否活着”，还要判断：

这个持有 Partition 的应用是否仍在推进消费循环。

这就是 Heartbeat 与 Poll Liveness 必须分开理解的原因。

2.1 poll() 并不等于同步 Fetch#

错误模型：

1
poll()
2
  ↓
3
发送 FetchRequest
4
  ↓
5
等待 FetchResponse
6
  ↓
7
返回这些 Record

更接近真实 Runtime 的模型：

1
检查 Subscription / Assignment
2
        ↓
3
推进 Group Coordination
4
        ↓
5
初始化缺失 Position
6
        ↓
7
从本地 Completed Fetch 读取
8
        ↓
9
必要时调度新的 FetchRequest
10
        ↓
11
处理网络事件
12
        ↓
13
反序列化可交付 Record
14
        ↓
15
更新 Position
16
        ↓
17
返回 ConsumerRecords

一次 poll() 可能：

• 直接返回上一次 Fetch 已缓存的数据；
• 发出新的 Fetch 但本轮没有数据可返回；
• 在 Rebalance 后执行 Callback；
• 从 Committed Offset 初始化 Position；
• 因为 auto.offset.reset 进行 Offset Reset；
• 只返回本地缓存中的一部分 Record。

2.2 Consumer 使用 Pull 的设计意义#

如果 Broker 主动 Push：

1
Broker 决定发送速度
2
        ↓
3
Consumer 处理能力不足
4
        ↓
5
客户端 Buffer 持续膨胀

Pull 模型使 Consumer 可以根据自己的节奏请求数据：

1
Consumer Capacity
2
       ↓
3
Fetch Timing / Fetch Size

这天然支持：

• Batch Fetch；
• 不同 Consumer 的独立速度；
• Consumer 侧 Backpressure；
• 失败后按 Position 重读；
• Broker 不需要维护每个消费者的业务处理窗口。

但 Pull 不代表完全没有预取。

Kafka Consumer 为了吞吐，会并行向多个 Broker 发 Fetch，并把结果缓存在客户端。

2.3 Fetch、缓存与 poll 的流水线#

典型流程：

1
FetchRequest N 已发出
2
        ↓
3
应用正在处理 poll N-1 返回的 Record
4
        ↓
5
FetchResponse N 到达本地缓存
6
        ↓
7
下一次 poll 从缓存交付数据
8
        ↓
9
同时调度 FetchRequest N+1

因此：

1
Network Fetch
2
        与
3
Application Processing

可以形成 Pipeline。

2.4 max.poll.records 不限制底层 Fetch 大小#

Kafka 4.3 默认：

1
max.poll.records = 500

它控制：

一次 poll() 最多向应用返回多少条 Record。

但官方配置明确说明，它不会改变底层 Fetch 行为。Consumer 可以把 FetchResponse 缓存在本地，再通过多次 poll 分批返回。2

所以：

1
FetchResponse = 3,000 records
2
max.poll.records = 500

可能表现为：

1
poll #1 → 500
2
poll #2 → 500
3
...

而不是 Broker 必须发送六次请求。

这对慢消费调优非常重要：

• 减少 max.poll.records 可以缩短单次业务处理时间；
• 但不一定减少网络 Fetch 或客户端内存规模；
• Fetch 内存仍受 fetch.max.bytes、max.partition.fetch.bytes 和 Batch 大小影响。

2.5 Fetch 的关键参数必须放回数据链#

1
吞吐和批量效率可能提升
2
延迟可能增加

1
满足最小字节
2
或
3
达到最长等待

2.6 Fetch 的并行单位#

Consumer 会根据当前 Assignment，把 Partition 按 Leader Broker 聚合：

1
P0 Leader → Broker 1
2
P1 Leader → Broker 2
3
P2 Leader → Broker 1

形成：

1
FetchRequest Broker 1
2
├── P0 offset=100
3
└── P2 offset=780
4

5
FetchRequest Broker 2
6
└── P1 offset=500

与 Producer 类似：

1
Partition 是顺序和 Position 单位
2
Broker Node 是网络请求聚合单位

2.7 poll() 返回后 Position 已经推进#

Kafka Javadoc 将 Position 定义为：

下一条将交付给应用的 Record Offset。

当 poll() 返回 Record 后，Consumer 的 Position 会自动前进。3

注意：

1
Position 已前进
2
        ≠
3
业务处理已经成功
4
        ≠
5
Committed Offset 已更新

这三个状态之间的间隔，是 At-Least-Once、At-Most-Once 和重复消费问题的根源。

3.1 Record Offset#

某条 Record 在特定 Partition Log 中的位置：

1
TopicPartition(order-events, 3)
2
Record Offset = 108

它的作用域永远是：

1
Topic + Partition

不同 Partition 可以同时存在 Offset=108。

3.2 Consumer Position#

Position 是：

下一条应该交付给当前 Consumer 的 Offset。

如果 poll 返回：

1
98, 99, 100

Position 通常推进到：

1
101

但 Offset 不保证绝对连续。

Log Compaction、事务控制记录或中止事务都可能让可见 Record 之间出现 Offset Gap。3

所以，不应该写：

1
nextOffset = lastOffset + 1;

然后假设下一条业务 Record 一定存在。

3.3 Committed Offset#

Committed Offset 是：

持久记录的恢复位置。

Consumer 重启或 Rebalance 获得 Partition 后，会从 Committed Offset 继续。

最重要的语义是：

1
Committed Offset
2
=
3
下一条应该重新读取的 Offset

如果已经成功处理 Offset 99，应该提交：

1
100

而不是 99。

3.4 Log End Offset#

Log End Offset（LEO）可概念化为：

Leader 本地 Log 的下一写入位置。

如果最后一条 Record Offset 为 149：

1
LEO = 150

LEO 包含 Leader 已追加但未必对普通 Consumer 可见的尾部范围。

3.5 High Watermark#

High Watermark（HW）表示：

普通 Consumer 可以安全读取的复制提交上界。

这里先理解为可见边界。

为什么 HW 不能简单等于 LEO，以及它如何跟随 Replica Fetch 推进，放到第五篇副本与可靠性中深入。

3.6 Last Stable Offset#

使用：

1
isolation.level=read_committed

时，Consumer 只返回已提交事务中的 Record。

如果 Log 中存在未完成事务，Consumer 可能只能读取到：

1
Last Stable Offset（LSO）

官方文档指出，read_committed Consumer 的可读终点是第一个 Open Transaction 之前的稳定位置，因此 LSO 可能落后于 HW。2

本篇只建立坐标。

Transaction Marker、Abort Index 与 LSO 推进机制在第五篇展开。

3.7 Lag 到底怎么算#

常见 Consumer Lag：

1
Lag
2
≈
3
Log End / 可读上界
4
-
5
Committed Offset 或 Current Position

但不同监控工具可能使用不同坐标：

• Broker Log End Offset；
• Consumer 可见上界；
• Current Position；
• Committed Offset；
• read_committed 下的 LSO。

因此看到：

1
Lag = 100,000

第一反应不应该是立刻扩容，而是确认：

1
这个 Lag 的右端点是什么？
2
左端点是 Committed 还是 Position？
3
是否存在事务阻塞？
4
是否存在暂停 Partition？
5
是否是单一 Hot Partition？

4.1 subscribe()：Kafka 管理 Ownership#

1
consumer.subscribe(List.of("order-events"));

应用声明：

1
我希望消费这些 Topic

Kafka Consumer Group 负责决定：

1
这个实例具体拥有哪些 Partition

它会使用：

• Group ID；
• Group Coordinator；
• Membership；
• Assignment Strategy；
• Rebalance；
• Committed Offset。

适用于绝大多数需要：

1
自动扩容
2
故障接管
3
实例动态变化

的业务消费者。

4.2 assign()：应用管理 Ownership#

1
consumer.assign(List.of(
2
    new TopicPartition("order-events", 0),
3
    new TopicPartition("order-events", 1)
4
));

此时动态分区分配和 Consumer Group Coordination 被禁用。3

应用自己负责：

• 哪个实例处理哪个 Partition；
• 实例数量变化；
• Partition 扩容；
• 故障接管；
• Ownership 冲突；
• Assignment 发布。

assign() 并不代表不能使用 Kafka Offset Commit。

如果配置 group.id，应用仍可提交 Offset，但 Kafka 不会替你动态分配 Partition。

4.3 两种模式不能混用#

一个 Consumer 不能同时：

1
subscribe()
2
+
3
assign()

除非先：

1
consumer.unsubscribe();

因为两种 API 的 Ownership 来源不同：

1
subscribe → Coordinator Assignment
2
assign    → Application Assignment

4.4 什么时候适合 assign()#

典型场景：

• 外部调度系统已经拥有 Shard Ownership；
• 固定 Partition 与物理实例绑定；
• 离线回放工具；
• 特殊数据修复；
• 测试和诊断；
• 需要完全绕开 Group Rebalance 的独立处理器。

普通业务服务不应该为了“避免 Rebalance”随意改用 assign()。

那只是把一个成熟协调协议替换成自行实现分布式 Ownership。

5.1 Group ID 定义消费视图#

1
group.id=order-fulfillment

所有使用同一 Group ID 的 Consumer 组成一个逻辑消费组。

同一 Topic 可以被多个 Group 独立消费：

1
Group fulfillment
2
Group risk
3
Group analytics
4
Group notification

每个 Group 拥有自己的：

1
Partition Assignment
2
Committed Offset
3
Lag
4
Processing Lifecycle

5.2 同一 Group 内的核心约束#

对传统 Consumer Group：

一个 Partition 在任一时刻只分配给同一 Group 中的一个 Consumer。

例如：

1
Topic = 8 Partitions
2
Group = 3 Consumers

可能分配：

1
Consumer A → P0 P1 P2
2
Consumer B → P3 P4 P5
3
Consumer C → P6 P7

这保证：

• Partition 内 Record 由单一 Consumer 顺序拉取；
• Position 不会由同组多个实例竞争推进；
• 故障时可以把 Ownership 转移给其他成员。

5.3 Consumer 数大于 Partition 数#

1
Partitions = 3
2
Consumers  = 5

最多只有三个 Consumer 获得有效 Partition。

其余实例空闲。

因此：

1
有效并行 Consumer 数
2
<=
3
Partition 数

这也是为什么看到 Lag 高时，不能无脑增加 Consumer。

5.4 一个 Consumer 可以拥有多个 Partition#

Kafka 不要求一 Consumer 一 Partition。

1
Partitions = 12
2
Consumers  = 3

每个 Consumer 大约拥有四个 Partition。

Consumer 会在多个 Partition 间 Fetch、缓存和返回 Record。

业务处理慢时，需要进一步判断：

• 每个 Partition 都慢；
• 只有一个 Hot Partition；
• 一个 Consumer 拥有过多 Partition；
• 外部依赖造成所有 Partition 阻塞。

5.5 Share Group 不是 Consumer Group 的简单新版#

Kafka 4.2 起 Share Groups 已生产可用，允许同一 Share Group 的多个消费者协作处理同一 Partition 中的 Record，并提供 Per-record Acknowledgement 与 Delivery Attempt Count。12

但它是另一套消费语义：

1
Consumer Group
2
→ Partition Ownership
3

4
Share Group
5
→ Record Acquisition / Acknowledgement

本专题仍以传统 Consumer Group 为主。

需要任务队列语义时，可以在扩展篇单独研究 Share Groups，不能把它和 KIP-848 Consumer Protocol 混为一谈。

6.1 Coordinator 是一个 Broker 角色#

Group Coordinator 并不是额外部署的独立服务。

某个 Broker 会成为特定 Consumer Group 的 Coordinator。

Consumer 首先通过：

1
FindCoordinator(group.id)

找到它。

之后，Join、Heartbeat、Commit 和 Offset Fetch 等 Group 请求都发往该 Broker。

6.2 Group ID 如何映射到 Coordinator#

简化理解：

1
hash(group.id)
2
    ↓
3
__consumer_offsets Partition
4
    ↓
5
该 Partition Leader Broker
6
    ↓
7
Group Coordinator

因此 Coordinator 的分布与内部 Offset Topic Partition 相关。

大量 Group 可以分散到不同 Coordinator Broker。

6.3 Coordinator 与 Controller 不同#

不要混淆：

1
Broker
2
Topic
3
Partition
4
Replica
5
Leader

1
Member
2
Subscription
3
Assignment
4
Offset Commit
5
Group Epoch

6.4 Coordinator 内存状态与持久状态#

Coordinator 会缓存：

1
Group Metadata
2
Committed Offset

以快速响应 Heartbeat、Join 与 OffsetFetch。

持久化的 Offset Commit 会写入：

1
__consumer_offsets

这是一个 Compacted Internal Topic。

当 Coordinator 发生迁移时，新 Coordinator 可以加载对应 Offset Topic Partition 重建缓存。4

7.1 FindCoordinator#

Consumer 先向任意 Broker 查询：

1
group.id 对应的 Coordinator 在哪里

获得：

1
Coordinator Node

后续 Group 请求发给该 Node。

如果 Coordinator 发生变化，Client 会标记旧 Coordinator 不可用并重新查找。

7.2 JoinGroup：汇报成员能力和订阅#

每个 Consumer 向 Coordinator 发送：

1
Member ID / Instance ID
2
Subscription
3
支持的 Assignment Strategies
4
Protocol Metadata
5
Rebalance Timeout

Coordinator 收集当前 Group 成员。

Classic Protocol 会选择一个成员作为：

1
Group Leader

注意：

Group Leader 是 Consumer Client，不是 Broker Leader。

7.3 Client-side Assignor 计算全组分配#

Coordinator 把成员和 Subscription 信息交给 Group Leader。

Group Leader 在客户端运行 Assignor：

1
GroupSubscription
2
        ↓
3
Range / RoundRobin / Sticky ...
4
        ↓
5
GroupAssignment

得到：

1
Member A → P0 P1
2
Member B → P2 P3

这就是 Classic Protocol 为什么把较多协调复杂性放在 Client。

7.4 SyncGroup：提交并分发 Assignment#

Group Leader 通过 SyncGroup 把每个成员的 Assignment 发给 Coordinator。

其他成员也发送 SyncGroup，等待 Coordinator 返回自己的 Assignment。

成功后 Group 进入：

1
Stable

Consumer 获得 Partition，初始化 Position，开始 Fetch。

7.5 Generation 的作用#

一次成功 Rebalance 会形成新的：

1
Generation

Offset Commit 等 Group 操作携带成员和 Generation 信息。

如果一个旧成员在 Rebalance 后继续提交：

1
旧 Generation
2
        ↓
3
CommitFailed / Fenced

这防止已经失去 Ownership 的 Consumer 覆盖新 Owner 的进度。

7.6 为什么 Classic Rebalance 很贵#

一次成员变化可能导致：

1
所有成员进入 Join
2
        ↓
3
等待成员集合稳定
4
        ↓
5
Group Leader 重算 Assignment
6
        ↓
7
所有成员 Sync
8
        ↓
9
执行 Revoke / Assign Callback
10
        ↓
11
重新初始化 Position 和 Fetch

它包含：

• 全组同步屏障；
• Partition Ownership 迁移；
• 本地缓存丢弃；
• Offset Commit；
• 状态重建；
• 外部资源初始化。

因此 Rebalance 的代价不能只用“几次网络请求”衡量。

8.1 Empty#

Group 没有活跃成员，但可能仍保存 Committed Offset。

首个成员加入后进入 Rebalance。

8.2 PreparingRebalance#

Coordinator 正在等待成员加入。

触发来源：

• 新成员；
• 成员离开；
• Session Timeout；
• Subscription 变化；
• Topic Partition 数变化；
• 显式 Rebalance；
• 协议或 Assignor 变化。

8.3 CompletingRebalance#

成员集合已经确定，正在等待 Assignment 同步。

此时：

• Group Leader 计算结果；
• 成员等待 SyncGroup；
• Assignment 尚未完全生效。

8.4 Stable#

成员拥有稳定 Assignment，正常：

1
Heartbeat
2
Fetch
3
Commit

8.5 Dead#

Group Coordinator 不再服务该 Group，例如内部 Partition 迁移或 Coordinator 关闭过程中。

8.6 状态机如何帮助排错#

如果 Commit 抛出：

1
RebalanceInProgressException

不是简单“网络不好”，而是 Group 正处于 Ownership 未稳定状态。

如果 Group 长时间：

1
PreparingRebalance

应该检查：

• 是否有成员持续 Join / Leave；
• 是否有实例无法在 Rebalance Timeout 内重新加入；
• Callback 是否耗时；
• Coordinator 是否不稳定；
• Assignor 配置是否不兼容。

Kafka 4.3 Monitoring 文档为 Classic Group 暴露：

1
PreparingRebalance
2
CompletingRebalance
3
Empty
4
Stable
5
Dead

等状态计数指标。5

9.1 RangeAssignor#

按 Topic 分别分配连续 Partition 区间。

例如两个 Topic：

1
Topic A: A0 A1 A2
2
Topic B: B0 B1 B2
3
Consumers: C1 C2

可能：

1
C1 → A0 A1 B0 B1
2
C2 → A2 B2

优点：

• 简单；
• 同 Topic Partition 连续；
• 适合某些局部性。

缺点：

• 多 Topic 下可能产生倾斜；
• 默认使用 Eager Rebalance。

Kafka 4.3 Classic Client 默认 Assignor 列表第一个仍是 Range，因此默认实际使用 Range。2

9.2 RoundRobinAssignor#

把所有已订阅 Partition 轮询分给成员。

优点：

• 在 Subscription 一致时总体更均衡。

缺点：

• Subscription 不一致时结果复杂；
• Assignment 变化时可能移动大量 Partition；
• 默认是 Eager。

9.3 StickyAssignor#

目标：

1
尽量平衡
2
+
3
尽量保留原 Assignment

减少 Rebalance 时 Partition 迁移。

但它仍是 Eager Rebalance Protocol：

1
成员先撤销全部 Ownership
2
再获得新 Assignment

所以“Sticky”主要描述分配结果稳定性，不等于增量 Ownership 迁移。

9.4 CooperativeStickyAssignor#

它使用 Sticky 分配思想，并启用 Cooperative Rebalance。

目标：

只撤销确实需要移动的 Partition。

Kafka 4.3 默认 Assignor 列表为：

1
RangeAssignor
2
CooperativeStickyAssignor

这样可以通过滚动升级移除 Range，把所有 Consumer 切换到 CooperativeSticky。2

9.5 Assignor 选择必须考虑什么#

不要只比较“均不均匀”。

至少评估：

1
Topic 数量
2
Subscription 是否一致
3
Partition 数量
4
Assignment 稳定性
5
Stateful Resource 初始化成本
6
Partition 迁移代价
7
Rebalance 停顿容忍度
8
滚动升级兼容

例如 Consumer 为每个 Partition 建立本地缓存或数据库连接时，Sticky 的价值会明显增加。

10.1 Eager Rebalance#

Eager 模型：

1
所有成员撤销全部 Partition
2
        ↓
3
全组重新分配
4
        ↓
5
成员获得新 Assignment

即使最终只有一个 Partition 需要从 A 移到 C，A 和 B 也可能都暂时停止所有 Partition。

这就是常说的：

1
Stop The World Rebalance

更准确地说，是：

Group 内 Partition Ownership 出现全量撤销窗口。

10.2 Cooperative Rebalance#

Cooperative 模型：

1
成员保留无需移动的 Partition
2
        ↓
3
仅撤销存在冲突的 Partition
4
        ↓
5
目标成员在旧 Owner 撤销后获取
6
        ↓
7
通过多轮增量收敛

核心安全条件：

同一 Partition 不能同时被两个成员拥有。

因此 Cooperative 不是“一步直接覆盖 Assignment”，而是：

1
Revoke
2
→ 确认释放
3
→ Assign

10.3 Cooperative 为什么可能需要多轮#

假设：

1
C1 当前拥有 P0 P1
2
C2 当前拥有 P2 P3
3
新增 C3

目标：

1
C1 → P0
2
C2 → P2
3
C3 → P1 P3

第一轮先让：

1
C1 revoke P1
2
C2 revoke P3

第二轮 C3 才能安全获得。

因此 Cooperative 减少停顿范围，但可能通过多轮 Rebalance 收敛。

10.4 回调语义也不同#

11.1 为什么重新设计协议#

Classic Protocol 的关键限制包括：

• Assignment 在 Client Group Leader 上计算；
• JoinGroup / SyncGroup 形成全组同步屏障；
• 大 Group 的 Subscription Metadata 很重；
• 一个成员变化容易影响全组；
• Client 配置控制 Heartbeat、Session 和 Assignor；
• Broker 很难独立增量推进每个成员状态。

新协议目标：

1
更大 Consumer Group
2
更短 Rebalance
3
Broker 端集中 Assignment
4
Fully Incremental
5
简化 Client
6
改进线程模型

11.2 Broker-side Assignor#

新协议中，Assignment Strategy 由 Broker 控制：

1
group.consumer.assignors=uniform,range

Kafka 4.3 默认提供：

1
uniform
2
range

默认优先：

1
uniform

Consumer 可以通过：

1
group.remote.assignor=range

请求 Broker 端可用 Assignor。1

这与 Classic 的：

1
partition.assignment.strategy

完全不同。

11.3 Member Epoch#

Classic Protocol 常围绕：

1
Generation

管理全组版本。

新协议更强调：

1
Member Epoch
2
Target Assignment
3
Current Assignment

每个成员通过 Heartbeat 持续汇报自己的状态。

Broker 返回：

• 当前成员 Epoch；
• 目标 Assignment；
• 需要 Revoke / Assign 的变化。

成员独立进行 Reconciliation。

11.4 Fully Incremental Reconciliation#

新协议不再要求：

1
所有成员同时停下
2
所有成员同时 Join
3
所有成员同时 Sync

而是：

1
Coordinator 更新目标 Assignment
2
        ↓
3
受影响成员逐步 Reconcile
4
        ↓
5
未受影响成员继续处理
6
        ↓
7
Group 最终收敛

官方文档明确指出，新协议不再依赖 Global Synchronization Barrier。1

11.5 新 Consumer Group 状态#

Kafka 4.3 Monitoring 中，新 Consumer Group 主要状态为：

1
Empty
2
Assigning
3
Reconciling
4
Stable
5
Dead

其中：

11.6 Heartbeat 与 Session 配置移动到 Broker#

使用新协议时，以下 Client 配置不再支持：

1
heartbeat.interval.ms
2
session.timeout.ms
3
partition.assignment.strategy
4
enforceRebalance()

改由 Broker 配置：

1
group.consumer.heartbeat.interval.ms
2
group.consumer.session.timeout.ms
3
group.consumer.assignors

统一管理 Group 的成员检测和 Assignment 策略。1

11.7 新协议并不消灭所有 Rebalance 成本#

即使 Fully Incremental，以下工作仍可能发生：

• Partition Revoke Callback；
• 未处理 Record 清理；
• Offset Commit；
• 新 Partition Position 初始化；
• State / Cache 初始化；
• 外部连接迁移；
• Hot Partition 转移；
• 大量成员同时滚动发布。

新协议减少协调放大效应，但业务自身的 Ownership Migration 成本仍然存在。

11.8 Classic Cooperative 与新 Consumer Protocol 不要混淆#

1
CooperativeStickyAssignor
2
→ Classic Protocol 上的 Cooperative Ownership 迁移
3

4
group.protocol=consumer
5
→ 新的 Broker-driven Consumer Protocol

两者都强调 Incremental，但协议结构不同。

11.9 升级策略#

Kafka 4.3 支持：

• Group 为空时离线切换；
• 满足兼容条件时滚动在线升级；
• 反向滚动降级。

但正式迁移前必须验证：

1
所有 Client 版本
2
自定义 Assignor / Metadata
3
监控指标
4
Callback 语义
5
Broker group configs
6
回滚路径

不能只改一个配置就直接全量生产发布。

12.1 Heartbeat Interval#

Classic Protocol：

1
heartbeat.interval.ms=3000

表示成员向 Coordinator 发送 Heartbeat 的期望间隔。

通常应小于 session.timeout.ms，官方建议一般不超过其三分之一。2

新 Consumer Protocol 中该 Client 配置无效，由 Broker：

1
group.consumer.heartbeat.interval.ms

控制。

12.2 Session Timeout#

Classic Protocol：

1
session.timeout.ms=45000

如果 Coordinator 在该时间内没有收到 Heartbeat：

1
Member 被认为失效
2
        ↓
3
移出 Group
4
        ↓
5
Partition 重新分配

新协议由 Broker：

1
group.consumer.session.timeout.ms

控制。

Session Timeout 关注：

Consumer 进程 / 网络是否仍能维持 Group Session。

12.3 max.poll.interval.ms#

默认：

1
max.poll.interval.ms=300000

它关注：

应用是否仍在持续调用 poll，推进业务消费循环。

即使 Heartbeat Thread 仍能发送 Heartbeat，如果应用长时间不 poll：

1
进程活着
2
Heartbeat 正常
3
业务处理卡死
4
Position 不再推进

这属于 Livelock。

Kafka 用 max.poll.interval.ms 防止一个“活着但不工作”的 Consumer 永久占有 Partition。2

12.4 为什么业务处理会触发 Rebalance#

代码：

1
while (true) {
2
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(1));
3

4
    for (ConsumerRecord<String, String> record : records) {
5
        slowRemoteApi(record); // 总处理时间 8 分钟
6
    }
7
}

如果：

1
max.poll.interval.ms = 5 分钟

Consumer 无法及时再次 poll。

Kafka 会认为它不再具备 Ownership 能力。

即使它最终处理完成，Commit 可能失败：

1
Partition 已经分给新 Member
2
旧 Member Commit
3
→ CommitFailedException

12.5 max.poll.records 与处理时间#

可以估算：

1
最大单批处理时间
2
≈
3
max.poll.records
4
×
5
单条最坏处理时间

如果：

1
500 records
2
×
3
1 second
4
=
5
500 seconds

已经超过 5 分钟。

此时可选：

• 降低 max.poll.records；
• 提高 max.poll.interval.ms；
• 批量处理；
• 优化外部依赖；
• pause Partition 后交给受控 Worker；
• 将业务工作与 Poll Thread 解耦，但必须维护每 Partition 顺序和 Commit 水位。

12.6 Static Membership#

配置：

1
group.instance.id=fulfillment-consumer-01

Consumer 成为静态成员。

短暂重启时，Coordinator 可以保留其 Member Identity 和 Assignment，减少瞬时 Rebalance。2

但 Static Membership 不是无限租约。

达到 max.poll.interval.ms 后，静态成员会停止发送 Heartbeat，Partition 在 Session Timeout 后重新分配。2

它适合：

• 实例有稳定唯一 ID；
• 滚动重启；
• 短暂网络抖动；
• Stateful Consumer。

风险：

• 重复 Instance ID 会 Fencing；
• Session Timeout 太大导致真正故障接管慢；
• 容器环境必须正确生成稳定且唯一的 ID。

12.7 不要用无限增大 Timeout 掩盖问题#

把：

1
session.timeout.ms
2
max.poll.interval.ms

改得非常大，只会：

• 延迟真实故障接管；
• 延迟 Partition 释放；
• 扩大 Lag；
• 隐藏业务线程卡死；
• 让发布和扩缩容变慢。

正确做法是先测量：

1
Poll 间隔分布
2
Batch Processing P99
3
Heartbeat RTT
4
Rebalance Duration
5
外部依赖 Timeout

再设置故障检测窗口。

13.1 新成员加入#

扩容：

1
C1 C2
2
   ↓
3
新增 C3

需要把部分 Partition 转移给 C3。

13.2 成员正常退出#

close() 或 LeaveGroup：

1
C2 离开
2
   ↓
3
C2 的 Partition 重新分配

正常关闭通常比直接 kill -9 更快释放 Ownership。

13.3 Session Timeout#

进程宕机、网络中断或 Heartbeat 停止：

1
Session Timeout
2
      ↓
3
Coordinator 移除成员
4
      ↓
5
Rebalance

13.4 Max Poll Interval#

应用处理卡住：

1
poll 不再推进
2
      ↓
3
成员失去消费资格
4
      ↓
5
Ownership 转移

13.5 Subscription 变化#

Consumer 调用：

1
subscribe(newTopics);

或者 Pattern Subscription 匹配到新 Topic。

13.6 Topic Partition 数变化#

Topic 扩容后，Group 需要把新增 Partition 纳入 Assignment。

13.7 Assignor / Protocol 变化#

滚动修改：

1
partition.assignment.strategy
2
group.protocol

可能触发协议协商和重新分配。

13.8 Coordinator 或内部 Topic 变化#

__consumer_offsets Leader 变化、Coordinator 迁移或 Broker 故障会导致 Client 重新查找 Coordinator，并可能影响 Group 进度。

14.1 onPartitionsRevoked#

在可控 Ownership 移交前调用。

常见工作：

• 提交已处理 Offset；
• Flush Partition 本地状态；
• 停止对应 Worker；
• 释放 Partition 专属资源；
• 保存外部 Checkpoint。

Callback 必须：

1
快速
2
有界
3
可观测
4
幂等

如果 Callback 执行分钟级远程 I/O，会拖慢整个 Rebalance。

14.2 onPartitionsAssigned#

新 Assignment 生效后调用。

常见工作：

• 读取外部 Offset；
• seek() 到自定义位置；
• 初始化 Partition State；
• 恢复缓存；
• 启动对应 Worker。

如果自定义 Offset 存在外部系统，应在这里恢复 Position。

14.3 onPartitionsLost#

表示 Partition Ownership 已经丢失，应用不应再假设自己能安全提交或完成最终处理。

典型场景：

• Session 已经过期；
• Coordinator 已经把 Partition 分给其他成员；
• 无法执行正常 Revoke 流程。

此时不要继续：

1
把旧 Member 的 Offset 当作最终权威提交

14.4 Callback 在哪里执行#

Rebalance Callback 通常在 Consumer 应用线程的 poll 流程中执行。

因此 Callback 的耗时直接影响：

1
poll latency
2
Rebalance duration
3
Group convergence
4
业务处理停顿

不要在 Callback 内启动不受控并发后立刻返回，否则可能在旧 Ownership 工作仍未结束时让新 Owner 开始处理。

15.1 Commit 的对象是恢复位置#

假设成功处理：

1
P0 Offset 0..99

应提交：

1
P0 → 100

含义：

重启后从 100 开始。

Commit 并不会删除 Kafka 中的 Record。

Retention 仍由 Topic 配置决定。

15.2 Offset Commit 如何持久化#

流程：

1
Consumer
2
    ↓ OffsetCommitRequest
3
Group Coordinator
4
    ↓ Append
5
__consumer_offsets
6
    ↓ Replication
7
CommitResponse

官方实现文档说明，Coordinator 把 Offset Commit 追加到 __consumer_offsets Compacted Topic，并在达到内部 Topic 的复制确认条件后返回成功；Coordinator 同时维护 Offset Cache 加速查询。4

15.3 enable.auto.commit=true#

Kafka 4.3 默认：

1
enable.auto.commit=true
2
auto.commit.interval.ms=5000

自动提交的是 Consumer 已经交付 / 推进的 Position。

它并不知道你的业务是否真正成功。

危险场景：

1
poll 返回 500 条
2
Position 已推进
3
Auto Commit 发生
4
业务只处理 100 条后进程崩溃

重启可能从提交后的更远位置继续，造成未处理 Record 被跳过。

因此包含重要业务副作用时，通常应：

1
enable.auto.commit=false

并由应用控制提交。

15.4 提交过早：At-Most-Once 风险#

1
Commit Offset
2
    ↓
3
执行数据库更新
4
    ↓
5
进程崩溃

重启从新 Offset 继续，旧 Record 不再重放。

业务更新可能丢失。

15.5 提交过晚：At-Least-Once 重复#

1
业务成功
2
    ↓
3
Commit 前进程崩溃
4
    ↓
5
重启重新消费

Record 会再次处理。

因此企业应用通常采用：

1
处理成功后提交
2
+
3
业务幂等

15.6 commitSync()#

同步等待 Commit 成功或失败：

1
consumer.commitSync();

优点：

• 错误直接返回；
• 顺序清晰；
• 适合 Revoke、关闭或关键 Checkpoint。

缺点：

• 阻塞 Poll Thread；
• Coordinator 慢时增加处理延迟；
• 每批都同步 Commit 会降低吞吐。

更安全的显式提交：

1
Map<TopicPartition, OffsetAndMetadata> offsets = new HashMap<>();
2
offsets.put(tp, new OffsetAndMetadata(lastProcessedOffset + 1));
3
consumer.commitSync(offsets);

15.7 commitAsync()#

1
consumer.commitAsync(offsets, callback);

优点：

• 不阻塞等待响应；
• 更适合高频提交。

风险：

1
Commit 100 发出
2
Commit 200 发出
3
Commit 200 成功
4
Commit 100 延迟失败 / 回调

如果应用在 Callback 中盲目重试 100，可能把恢复点倒退。

需要维护：

1
Monotonic Commit Watermark

只允许提交进度向前。

15.8 常见组合#

业务循环中：

1
周期性 commitAsync

Rebalance / Close 时：

1
最后一次 commitSync

这样兼顾吞吐和退出确定性。

但仍要检查当前 Assignment 与处理水位。

15.9 多线程处理时提交什么#

假设 Poll Thread 把同一 Partition 的 Record 交给 Worker：

1
Offset 100 完成
2
Offset 101 仍处理中
3
Offset 102 完成

不能提交：

1
103

否则 101 失败后无法重放。

可提交的水位是：

从旧 Position 开始，已经连续完成的最大前缀的下一 Offset。

即：

1
Completed: 100, 102
2
Gap: 101
3
Safe Commit = 101

这就是多线程 Consumer 最难的部分之一。

15.10 Commit 不能解决外部副作用 Exactly Once#

1
Kafka Record
2
    ↓
3
更新 MySQL
4
    ↓
5
Commit Kafka Offset

MySQL Transaction 与 Kafka Offset Commit 是两个系统。

中间崩溃仍可能重复。

第五篇和第六篇会继续讨论：

• Idempotent Consumer；
• Unique Key；
• Outbox；
• Kafka Transaction；
• Read-Process-Write EOS 边界。

16.1 Assignment 后从哪里开始#

Consumer 获得 Partition 后：

1
存在 Committed Offset
2
→ 从 Committed Position 开始
3

4
不存在或 Offset 已过期
5
→ 使用 auto.offset.reset

16.2 auto.offset.reset#

Kafka 4.3 支持：

1
earliest
2
latest
3
by_duration:<ISO-8601 duration>
4
none

例如：

1
auto.offset.reset=earliest

从当前最早可用位置开始。

1
auto.offset.reset=latest

从当前最新位置开始，只消费后续 Record。

1
auto.offset.reset=by_duration:PT6H

尝试从当前时间向前六小时对应的位置开始。2

1
auto.offset.reset=none

没有有效 Committed Offset 时直接失败，适合不允许静默跳转的关键系统。

16.3 Offset 为什么会失效#

• Retention 删除旧 Segment；
• Group 长期不活跃导致 Offset 过期；
• 管理员 Reset Offset；
• Topic 重建；
• Partition 发生变化；
• 外部错误提交。

16.4 seek()：移动当前 Position#

1
consumer.seek(tp, offset);

改变当前 Consumer 的读取 Position。

它不会自动修改 Committed Offset。

所以：

1
seek(100)
2
        ↓
3
从 100 重读
4
        ↓
5
如果未 Commit
6
重启仍从原 Committed Offset

16.5 Replay 的两种方式#

1
kafka-consumer-groups.sh \
2
  --bootstrap-server localhost:9092 \
3
  --group order-fulfillment \
4
  --topic order-events \
5
  --reset-offsets \
6
  --to-earliest \
7
  --execute

17.1 Lag 上升的基本模型#

设：

1
Producer Rate = λ
2
Consumer Processing Rate = μ

当：

1
λ > μ

Lag 会持续增长。

但根因可能在不同层：

1
Partition 不足
2
Consumer 不足
3
单 Partition 热点
4
Fetch 慢
5
反序列化慢
6
业务处理慢
7
DB / API 慢
8
Commit 慢
9
频繁 Rebalance

17.2 pause() 不会释放 Ownership#

1
consumer.pause(partitions);

表示暂时不从这些 Partition 向应用交付新 Record。

它不会：

• 退出 Group；
• 触发 Rebalance；
• 把 Partition 给其他 Consumer。

适用于：

• Worker Queue 已满；
• 下游限流；
• 单 Partition 暂停；
• 保持 Poll / Heartbeat，同时停止获取更多业务工作。

恢复：

1
consumer.resume(partitions);

17.3 Poll Thread + Worker Pool#

常见架构：

1
Poll Thread
2
    ↓
3
按 Partition 分发
4
    ↓
5
Partition Worker / Ordered Queue
6
    ↓
7
业务处理
8
    ↓
9
Completed Offset Tracker
10
    ↓
11
Commit Safe Watermark

关键规则：

1. 同一 Partition 的业务顺序必须受控；
2. Poll Thread 仍需持续 poll；
3. Worker Queue 满时 pause；
4. 只提交连续完成前缀；
5. Revoke 时停止接收新任务并等待 / 取消旧任务；
6. Ownership Lost 后不再提交旧结果。

这不是简单：

1
records.parallelStream().forEach(this::handle);

17.4 什么时候应该扩 Consumer#

同时满足：

1
存在未利用 Partition 并行度
2
处理瓶颈可通过更多实例分摊
3
下游系统也能承受扩容流量
4
Assignment 和 Rebalance 成本可控

如果：

1
Partitions = Consumers

继续加 Consumer 没有直接效果。

如果只有 P7 是 Hot Partition，加十个 Consumer 也无法拆分 P7 内部顺序流。

18.1 Fetch 层#

关注：

1
fetch-rate
2
fetch-latency-avg / max
3
fetch-size-avg / max
4
records-per-request-avg
5
bytes-consumed-rate
6
records-consumed-rate

判断：

• Fetch 是否频繁但 Batch 很小；
• Broker 响应是否变慢；
• 网络是否成为瓶颈；
• Consumer 是否真正有数据流入。

18.2 Lag 层#

1
records-lag
2
records-lag-max
3
records-lead

必须按 Partition 观察。

总 Lag 可能掩盖：

1
一个 Hot Partition
2
+
3
大量空闲 Partition

18.3 Poll 与处理层#

1
last-poll-seconds-ago
2
time-between-poll-avg / max
3
poll-idle-ratio-avg
4
records-consumed-rate

如果：

1
time-between-poll-max
2
接近 max.poll.interval.ms

说明业务处理已经接近失去 Ownership。

18.4 Coordinator 与 Rebalance#

Classic / Consumer 指标关注：

1
assigned-partitions
2
heartbeat-rate
3
heartbeat-response-time-max
4
last-heartbeat-seconds-ago
5
rebalance-total
6
rebalance-rate-per-hour
7
last-rebalance-seconds-ago
8
failed-rebalance-total

Broker 侧 Kafka 4.3 还暴露：

1
consumer-group-count{state}
2
consumer-group-rebalance-rate
3
classic group completed rebalance rate
4
offset-commit-rate

等 Group Coordinator 指标。5

18.5 Commit#

1
commit-rate
2
commit-latency-avg
3
commit-latency-max
4
commit-failed-rate

Commit 慢可能意味着：

• Coordinator Broker 压力；
• __consumer_offsets 副本问题；
• 网络抖动；
• Group 正在 Rebalance；
• Commit 过于频繁。

18.6 指标必须组合解释#

例如：

1
Lag ↑
2
records-consumed-rate ↓
3
fetch-latency 正常
4
time-between-poll ↑

更可能是业务处理慢，而不是 Broker Fetch。

1
Lag ↑
2
fetch-latency ↑
3
heartbeat 正常
4
业务 CPU 低

更可能是 Broker、网络或 Quota。

19.1 症状：Lag 持续上升#

按顺序检查：

1
Group 是否 Stable？
2
Rebalance Rate 是否异常？
3
Assigned Partitions 是否减少？
4
是否存在空闲 Consumer？

1
Leader 是否可用？
2
Fetch Latency 是否升高？
3
是否有大 Batch 卡住？
4
Broker Quota / TLS 是否异常？

1
DB / HTTP P99
2
Worker Queue
3
GC
4
CPU
5
Hot Partition

1
Committed Lag 高但 Position Lag 低？
2
Commit 是否过慢或失败？

19.2 症状：重复消费突然增多#

检查：

• 业务成功后 Commit 前崩溃；
• Commit 失败；
• Rebalance 期间未提交；
• Async Commit Callback 重试倒退；
• Offset 被人工 Reset；
• Consumer 被频繁 Kill；
• 外部系统不幂等；
• Worker 完成顺序与 Commit 水位错误。

19.3 症状：频繁 Rebalance#

检查：

1
实例是否频繁重启？
2
max.poll.interval 是否过小？
3
Callback 是否太慢？
4
session timeout 是否过小？
5
网络是否丢 Heartbeat？
6
容器 group.instance.id 是否冲突？
7
Assignor 列表是否一致？
8
Topic Pattern 是否频繁匹配变化？

19.4 症状：Consumer 存活但不再处理#

可能是：

• Poll Thread 死锁；
• Worker Queue 阻塞；
• Deserializer 卡住；
• Rebalance Callback 卡住；
• 所有 Partition 被 Pause；
• wakeup() 状态处理错误；
• read_committed 被 Open Transaction 阻挡；
• Consumer 没有 Assignment。

19.5 症状：增加 Consumer 后吞吐不升#

检查：

1
Partition 数是否足够？
2
是否只有单个 Hot Partition？
3
Assignor 是否导致倾斜？
4
下游 DB 是否已经饱和？
5
Broker / Network 是否瓶颈？
6
新 Consumer 是否真正获得 Assignment？

20.1 公共入口#

阅读：

1
KafkaConsumer
2
Consumer
3
ConsumerDelegate
4
ConsumerConfig
5
SubscriptionState
6
ConsumerMetadata

重点问题：

1. KafkaConsumer 如何选择 Delegate？
2. subscribe、assign、poll、commit、seek 如何委托？
3. SubscriptionState 保存哪些 Position 与 Assignment？
4. Thread Ownership 如何检查？
5. wakeup 如何跨线程生效？

20.2 Classic Client 路线#

建议阅读：

1
ClassicKafkaConsumer
2
ConsumerCoordinator
3
AbstractCoordinator
4
Heartbeat
5
HeartbeatThread
6
ConsumerNetworkClient
7
Fetcher / FetchCollector
8
SubscriptionState

关注：

1
updateAssignmentMetadataIfNeeded
2
pollForFetches
3
processBackgroundEvents / callbacks
4
return ConsumerRecords

1
ensureCoordinatorReady
2
ensureActiveGroup
3
onJoinPrepare
4
performAssignment
5
onJoinComplete
6
commitOffsetsSync / Async
7
maybeAutoCommit

1
FindCoordinator
2
JoinGroup
3
SyncGroup
4
Heartbeat Thread
5
Generation / Member ID
6
Rejoin Need

20.3 新 Async Consumer 路线#

阅读：

1
AsyncKafkaConsumer
2
ApplicationEventHandler
3
ConsumerNetworkThread
4
NetworkClientDelegate
5
ConsumerMembershipManager
6
HeartbeatRequestManager
7
CommitRequestManager
8
FetchRequestManager
9
OffsetsRequestManager
10
BackgroundEventProcessor

关注：

1. Application API 如何转换为 Event？
2. ConsumerNetworkThread 如何 poll 网络？
3. Heartbeat Response 如何推进 Member Epoch？
4. Target Assignment 与 Current Assignment 在哪里 Reconcile？
5. Rebalance Callback 如何回到应用线程？
6. Commit Future 如何跨线程完成？
7. Fetch Buffer 如何交付给 poll？

20.4 Broker Group Coordinator 路线#

阅读：

1
GroupCoordinatorService
2
GroupCoordinatorShard
3
GroupMetadataManager
4
OffsetMetadataManager
5
ClassicGroup
6
ConsumerGroup
7
ConsumerGroupMember
8
TargetAssignmentBuilder

关注：

1
PreparingRebalance
2
CompletingRebalance
3
Stable
4
Generation
5
Protocol
6
Leader

1
Group Epoch
2
Member Epoch
3
Target Assignment
4
Current Assignment
5
Assigning / Reconciling / Stable