用RdKafka::KafkaConsumer配合一致的group.id、禁用自动提交、合理的心跳与会话超时配置，并通过subscribe()由Kafka自动分配分区，即可实现负载均衡消费；忽略再平衡回调或参数不匹配易导致丢数或重复。
直接结论：用 RdKafka::KafkaConsumer + 正确的 group.id 配置 + 合理的再平衡回调，就能实现负载消费；不写回调也能工作，但容易在扩容/宕机时丢数据或重复消费。
如何配置消费者并加入同一消费者组
关键不是“怎么连 Kafka”，而是让多个 C++ 进程被识别为同一个逻辑组。这完全依赖 group.id 参数的一致性：
-
group.id必须是字符串常量（如"order-processor"），所有要协同工作的进程必须使用完全相同的值 -
bootstrap.servers要指向同一集群，否则协调者（Group Coordinator）无法统一管理 - 不要手动指定
partition—— 使用subscribe()订阅主题，由 Kafka 自动分配分区 - 必须设置
enable.auto.commit=false，否则自动提交可能在消息处理中途就提交 offset，导致故障时丢失
示例片段：
auto conf = RdKafka::Conf::create(RdKafka::Conf::CONF_GLOBAL);
conf->set("bootstrap.servers", "kafka-broker1:9092,kafka-broker2:9092", errstr);
conf->set("group.id", "order-processor", errstr); // ? 所有实例必须一致
conf->set("enable.auto.commit", "false", errstr);
conf->set("auto.offset.reset", "earliest", errstr);
conf->set("session.timeout.ms", "45000", errstr);
conf->set("heartbeat.interval.ms", "15000", errstr); // 心跳必须 < session.timeout / 3
为什么必须实现 rebalance_cb
不写回调，RdKafka 会用默认逻辑完成分区分配，但你将失去对位移和状态的控制权。真实生产中，以下问题几乎必然发生：
立即学习“C++免费学习笔记（深入）”；
- 消费者启动时想从特定 offset 恢复（比如上一次处理失败的位置），但没回调就无法调用
seek() - 消费者被踢出组前，来不及提交已处理但未 commit 的 offset，导致重启后重复消费
- 收到
RdKafka::ERR_REVOKE_PARTITIONS时不做commit_sync()，就可能丢失最后一批消息的进度 - 收到
RdKafka::ERR_ASSIGN_PARTITIONS后不主动seek()到正确位置，可能从头消费或跳过部分消息
最小可用回调骨架：
class RebalanceCb : public RdKafka::RebalanceCb {
public:
void rebalance_cb(RdKafka::KafkaConsumer *consumer,
RdKafka::ErrorCode err,
std::vector<RdKafka::TopicPartition*> &partitions) override {
if (err == RdKafka::ERR__ASSIGN_PARTITIONS) {
consumer->assign(partitions); // 接收新分区
// 可在此处 seek() 到自定义 offset
} else if (err == RdKafka::ERR__REVOKE_PARTITIONS) {
consumer->commitSync(); // ✅ 强制提交当前 offset
consumer->unassign(); // 释放分区
}
}
};
分区分配不均？检查消费者数量与主题分区数的关系
Kafka 不会把一个分区拆给多个消费者，也不会让一个消费者空转——但它的公平性取决于两个数字的比值：
- 如果主题只有 3 个分区，而你启了 5 个同
group.id的消费者，那其中 2 个会全程空闲（partitions.size() == 0） - 默认策略
RangeAssignor在多主题场景下容易倾斜（例如主题 A 有 8 分区、主题 B 有 1 分区，2 个消费者可能分到 A:0-3/B 和 A:4-7） - 想更均匀，显式配置
partition.assignment.strategy为"roundrobin"或"sticky" - 运行时可通过
kafka-consumer-groups.sh --describe --group order-processor查看实际分配结果
配置方式（加在 global config 中）：
conf->set("partition.assignment.strategy",
"org.apache.kafka.clients.consumer.RoundRobinAssignor", errstr);
最容易被忽略的点：心跳与会话超时的配合
很多“消费者突然掉线”“频繁 rebalance”问题，根源不在代码逻辑，而在这两个参数的数值关系：
-
session.timeout.ms是 Coordinator 判定消费者是否存活的依据（默认 45s） -
heartbeat.interval.ms是消费者发心跳的间隔（默认 3s），它必须严格小于session.timeout.ms / 3 - 如果你把
session.timeout.ms改成 60000（10 秒），却忘了调小heartbeat.interval.ms，那么心跳跟不上，Coordinator 立刻触发 rebalance - C++ 客户端不会自动帮你校验这个比例，填错就静默失效
建议组合（兼顾稳定性与响应速度）：
conf->set("session.timeout.ms", "45000", errstr); // 45s
conf->set("heartbeat.interval.ms", "15000", errstr); // ✅ 15s < 45s/3
