第 6 章 消费者组：独立进度、协作与再均衡

先做“组间独立”实验

开两个消费者终端，使用不同组：

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic orders --from-beginning --group notification-demo

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic orders --from-beginning --group analytics-demo

首次运行且历史数据仍保留时，两边都能读到全部三条记录。再发送一条新订单，两边都会看到。这分别对应通知服务与统计服务。

再做“组内分工”实验

开两个终端，执行同一条命令：

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic orders --from-beginning --group workers-demo \
  --property print.partition=true --property print.key=true

这两个消费者共同分担三个分区。历史记录可能在第二个进程启动前已经被第一个读完，因此不要只看启动时的输出。等组稳定后，再通过上一章的生产者发送多个不同 Key 的新事件。

查看分配和进度：

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe --group workers-demo

同一个分区会对应一个当前负责它的消费者。同一个消费者可以负责多个分区。不同 Key 可能哈希到同一个分区，所以少量事件不保证两个终端都立刻有输出。

什么是再均衡

组里有人加入、退出，或者订阅主题的分区发生变化时，分区分配需要调整，这叫 Rebalance，中文常译“再均衡”。退出一个消费者后，剩余成员会接管它的分区。

再均衡可能造成短暂等待，也可能让尚未提交进度的记录被再次处理。业务应用需要正确处理分区撤销、任务结束和提交进度。Kafka 4.x 有新的消费者组协议能力，但具体启用方式受客户端和 Broker 配置影响；本书不依赖把旧客户端参数原样迁移到新协议。

用分配表验证接管

判断再均衡是否完成，不能只看“第二个进程启动成功”。先确认三个分区被一个成员覆盖，加入第二个后确认仍恰好覆盖这三个分区且由两个成员分担，再停止第二个，等待第一个重新负责全部分区。观察期间可能出现临时无分配或过渡状态，应等待稳定后再比较。

随书 scripts/run_lab.py 按这三个阶段读取组描述并检查成员与分区覆盖。它证明受控启动、加入与退出后的分配行为，不证明真实业务的在途任务已经正确交接；异步业务仍要自行处理撤销、提交与幂等。

本章自测：把消费者数量从 3 加到 30，就能让三个分区快十倍吗？不能。先看分区并行度，再看真正的瓶颈。