嘿，我看到你在写C++的Kafka消费者代码时碰到了这个头疼的错误，刚好我之前在处理librdkafka相关项目时踩过类似的坑，来给你理理清楚到底是怎么回事，该怎么解决～

首先得搞懂这个错误的本质：Kafka里每个消费者组都有一个专门的「协调者broker」，负责管理这个组的offset、重平衡这些核心事儿。当你的消费者跑去和不是它所在组协调者的broker，请求消费、提交offset这类操作时，就会弹出这个「Not coordinator」的错误。

结合你贴的代码片段（你是先创建生产者去拿分区数对吧？），我整理了几个最常见的原因和对应的解决办法：

• 别硬编码broker地址，给足完整的bootstrap servers列表
  很多人图省事只填一个broker地址当bootstrap，要是这个broker刚好不是你消费者组的协调者，或者之后挂了，消费者就找不到正确的协调者了。一定要把集群里所有可用的broker地址都填到bootstrap_servers里，让消费者自己通过这些地址去发现集群的完整元数据，包括当前谁是协调者。

• 别用生产者的元数据给消费者凑合用
  你代码里用生产者去获取分区数的操作其实有隐患：生产者拿到的元数据和消费者需要的元数据可能不同步，尤其是如果集群刚发生过协调者选举、broker上下线的情况。应该让消费者自己去获取分区信息和元数据——直接用消费者实例调用metadata()方法就能拿到，这样能保证消费者拿到的是和自己协调者完全匹配的最新元数据，不会出现“找错人”的情况。

• 检查group.id配置，别搞混消费者组
  每个消费者组的协调者是Kafka根据group.id来分配的，要是你不小心给消费者配错了group.id，或者多个不同业务用了同一个group.id，就会导致消费者去找不属于自己的协调者，自然就报错了。确保你的消费者用的group.id是唯一的、和业务匹配的。

• 调整元数据刷新频率，跟上集群变化
  要是你的Kafka集群经常有broker上下线、协调者切换的情况，可以把librdkafka的metadata.max.age.ms配置调小一点——默认是5分钟，改成1分钟甚至更短，这样消费者会更频繁地刷新元数据，及时发现协调者的变化，不会抱着旧的元数据死磕。

• 错误重试别偷懒，让消费者有机会“重新找对人”
  当出现这个错误时，别直接让程序崩溃。librdkafka默认会自动处理这类元数据错误并重试，但如果你的代码里禁用了自动重试，就手动捕获这个错误，调用rd_kafka_metadata()强制刷新元数据，等个几秒再重试消费请求。一般重试个一两次就能找到正确的协调者了。

最后再给你提个小建议：把你代码里那个用生产者拿分区数的逻辑换成消费者自己获取，这样整个流程的元数据都是统一的，能从根源上避免很多这类协调者相关的问题。

备注：内容来源于stack exchange，提问作者sunmat