关键配置是 group.id 必须一致，enable.auto.commit 和 auto.offset.reset 需按场景设置；负载均衡由 broker 协调自动完成，无需手动实现；rebalance 由成员变动或心跳超时触发，librdkafka 自动处理；验证需用 rd_kafka_assignment() 查实际分配分区。
用 librdkafka 实现 Consumer Group 的核心配置
直接能跑起来的关键是 group.id 必须一致，且 enable.auto.commit 和 auto.offset.reset 要按场景选。Kafka 消费组的负载均衡不是靠代码写逻辑，而是靠 broker 协调 + 客户端心跳 + 分区分配策略自动完成的——你只要让多个实例用同一个 group.id 连同一组 topic，broker 就会把 topic 的不同 partition 分配给不同 client。
常见错误：本地起两个进程但用了不同 group.id，结果各自全量拉取所有分区，完全没负载均衡；或者忘了设 enable.auto.commit=true（默认是 true，但显式写出来更安全），导致重启后重复消费。
-
group.id设为字符串常量（如"my-group"），所有实例必须完全一致 -
enable.auto.commit推荐保持true，除非你要手动控制 offset 提交时机 -
auto.offset.reset选"earliest"或"latest"，新 group 启动时才生效；已有 group 以已提交 offset 为准 - 别碰
partition.assignment.strategy，默认"range"或"cooperative-sticky"都够用，改了反而容易失衡
订阅 topic 后触发 rebalance 的实际表现
rebalance 不是“每秒发生一次”，而是在成员加入/退出、心跳超时（session.timeout.ms 默认 45s）、或 coordinator 检测到元数据变更时触发。你写的 C++ 代码里不用监听或干预它，librdkafka 内部会自动处理分区重分配，并通过 rd_kafka_conf_set_rebalance_cb() 通知你——但绝大多数场景下，你只需要确保消息循环不卡住就行。
容易踩的坑：在 rebalance_cb 回调里做耗时操作（比如同步写 DB），会导致心跳发不出去，被踢出 group；或者忘记在 RD_KAFKA_RESP_ERR__REBALANCE_IN_PROGRESS 错误时跳过 rd_kafka_consumer_poll() 的返回值处理。
- rebalance 期间
rd_kafka_consumer_poll()可能返回NULL，此时不要当异常处理 - 如果用了手动 commit，务必在
RD_KAFKA_RESP_ERR__ASSIGN_PARTITIONS后调用rd_kafka_assign()，在RD_KAFKA_RESP_ERR__REVOKE_PARTITIONS后调用rd_kafka_assign(NULL) -
session.timeout.ms建议设为 6~12s，太短易误踢，太长故障恢复慢
多实例启动时如何验证负载均衡是否生效
最直接的办法是看每个实例实际消费的 partition 列表，而不是只盯日志里有没有“正在消费”。librdkafka 提供 rd_kafka_assignment() 获取当前分配的 partition，配合 rd_kafka_topic_partition_list_dump() 打印出来，一眼就能看出是不是真分摊了。
别依赖 “log 中消息数量差不多” 来判断——因为 partition 数据量本身就不均，且 consumer 拉取速度受网络、反序列化开销影响，单看吞吐没意义。
- 启动两个实例，都订阅同一个 topic（如
"test-topic"），topic 有 6 个 partition → 理想情况是一个实例拿到 3 个，另一个也拿到 3 个 - 用
rd_kafka_assignment()在 poll 循环开始前查一次，比对两次输出 - 用
kafka-topics.sh --bootstrap-server ... --describe --topic test-topic确认 topic 确实有多个 partition - 如果始终只有一个实例在消费，先检查
group.id是否拼错，再查 broker 日志里有没有MemberId not valid类报错
offset 提交失败会导致重复消费，但不是每次都会暴露
自动提交失败（比如网络抖动、broker 不可用）时，librdkafka 会重试，默认最多 3 次（offset.store.method=broker 时），但如果重试窗口内 client 退出，那这部分 offset 就丢了。下次启动仍从上次成功提交的位置读，中间消息就重复了。
真正难调试的是“看起来正常但偶尔重复”的 case：比如某次 poll 拿到 100 条，处理到第 80 条时进程被 kill，自动提交没来得及发出去，重启后又从第 0 条开始拉——这取决于你处理逻辑是否幂等，而不是 client 有没有 bug。
- 关键参数：
auto.commit.interval.ms默认 5s，可缩短到 1~2s 降低重复窗口，但会增 broker 压力 - 若业务要求强一致性，必须关掉自动提交（
enable.auto.commit=false），并在消息处理成功后立刻调用rd_kafka_commit() - 注意
rd_kafka_commit()是异步的，要检查返回值，失败时需重试（建议带指数退避） - 别在消息处理函数里直接 sleep 或阻塞 IO，否则会拖慢心跳和提交节奏
实际部署时，partition 数量、实例数、消息处理耗时三者不匹配，才是负载不均的主因。比如 4 个 partition 起 5 个实例，必然有一个实例空转；而 100 个 partition 起 2 个实例，每个就得扛 50 个，CPU 或反序列化瓶颈就暴露了。这些没法靠改 client 代码解决。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
