这种情况我碰到过好几次，大概率是消费者配置或者消费组逻辑的问题，咱们一步步排查解决：

1. 先确认消费者组ID是否一致 #

Kafka的分区分配核心逻辑是基于消费者组的：同一个组内的消费者会分摊Topic的分区；不同组则各自独立消费全部分区。如果第二台VM的消费者没分到分区，先检查这个最基础的点：

• 确保两台机器的消费者配置里，group.id参数完全相同（大小写敏感，别打错字符）！
• 用Kafka命令行工具直接验证消费组状态，一眼就能看到问题：

  kafka-consumer-groups.sh --bootstrap-server <你的Kafka集群地址> --describe --group <你的group.id>
  

  这个命令会列出该组下的所有消费者实例，以及它们分配到的分区，能直接判断第二台机器的消费者有没有被集群识别到。

2. 检查Topic分区数是否足够 #

如果你的Topic分区数小于消费者组内的消费者数量，那必然会有部分消费者拿不到分区——因为Kafka规定，同一个消费组内，一个分区只能分配给一个消费者。

• 先确认Topic的分区数量：

  kafka-topics.sh --bootstrap-server <你的Kafka集群地址> --describe --topic <你的Topic名称>
  

  如果分区数不足，直接扩容分区即可（注意：Kafka的分区数只能增加，不能减少）。

3. 排查分区分配策略与超时配置 #

默认的Range分配策略在某些场景下可能导致分配不均，但不会完全不给某台机器分配。不过如果消费者的超时配置不合理，可能会被集群判定为下线，从而收回分区：

• 如果分区数足够但分配不均，可以尝试修改分配策略为RoundRobin，让分区更均匀地分配给消费者：
  在消费者配置中添加：

  partition.assignment.strategy=org.apache.kafka.clients.consumer.RoundRobinAssignor
  

• 检查超时配置：如果第二台VM网络延迟高，或者消费者处理消息耗时过长，可能触发集群的下线判定。可以适当调大以下参数：

  # 消费者会话超时时间，默认30000ms
  session.timeout.ms=60000
  # 心跳间隔，默认3000ms，建议设为session超时的1/3左右
  heartbeat.interval.ms=10000
  # 两次poll操作的最大间隔，默认300000ms
  max.poll.interval.ms=600000
  

4. 确认消费者是否正常连接集群 #

有时候第二台VM的消费者可能因为网络问题（比如防火墙没开Kafka端口）、集群地址配置错误，导致根本没加入到消费组里：

• 查看第二台VM的消费者日志，检查是否有连接失败、加入消费组失败的报错信息；
• 用之前的kafka-consumer-groups.sh命令，确认消费组的成员列表里是否有第二台机器的实例。

5. 清理 stale 的消费组会话 #

如果第二台VM的消费者之前异常退出，但Kafka还没清理它的会话，可能导致分区被“占用”：

• 可以手动重置消费组的偏移量（会触发重新分配分区，可能导致重复消费，谨慎操作）：

  kafka-consumer-groups.sh --bootstrap-server <你的Kafka集群地址> --reset-offsets --group <你的group.id> --topic <你的Topic名称> --to-earliest --execute
  

• 或者直接删除消费组（仅当组内没有运行的消费者时可用）：

  kafka-consumer-groups.sh --bootstrap-server <你的Kafka集群地址> --delete --group <你的group.id>
  

快速排查流程总结 #

1. 验证两台消费者的group.id完全一致
2. 确认Topic分区数 ≥ 消费组内的消费者数量
3. 用命令行工具查看消费组的成员和分区分配状态
4. 检查消费者的网络连接与超时配置
5. 必要时重置或删除异常的消费组会话

内容的提问来源于stack exchange，提问作者Tejas 07