Kafka producer仅向4个分区中的1个发送消息故障排查咨询

1. 排查实例本地的客户端配置差异 #

• 优先对比该异常实例和正常实例的运行时全量librdkafka配置，确认是否存在本地配置文件、环境变量覆盖了分区相关参数：librdkafka默认分区器为consistent_random，如果被误设为fixed，或是sticky分区器的粘滞配置被修改，都会导致所有消息打入同一分区。
• 重点核对partitioner、sticky_partitioning_linger_ms、partitioner_ignore_key三个参数的取值是否和正常实例一致。

2. 排查消息属性与系统基础能力异常 #

• 确认该实例发送的消息是否全部携带同一个key：默认一致性哈希分区器会把相同key的消息打入同一分区，可以临时增加日志打印每条消息的key值做校验。
• 验证该VM的随机数生成能力是否正常：librdkafka默认分区器依赖系统随机数做无key消息的分区分配，如果/dev/urandom存在读取权限异常、随机数种子初始化失败的问题，会导致每次计算出的分区号固定为0，可运行以下测试代码验证：

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main() {
    srand(time(NULL));
    for(int i=0;i<10;i++) printf("%d\n", rand()%4);
    return 0;
}

如果输出结果全部为0，即可确认随机数生成链路存在问题。

3. 排查集群元数据同步与网络连通性 #

• 开启librdkafka的debug=metadata日志，确认该实例拉取到的目标topic分区数是否为4：如果元数据拉取超时、或元数据被篡改，客户端会默认topic只有1个分区，所有消息打入分区0。
• 测试该VM到两个broker的9092端口连通性：如果防火墙策略只放通了分区0 leader所在broker的访问权限，客户端会 fallback 到仅写入可达broker上的分区。

• 配置覆盖问题：删除本地异常的分区器配置，恢复为默认的consistent_random即可。
• 随机数生成异常：修复/dev/urandom的读取权限，或是显式配置partitioner=round_robin绕过随机数依赖。
• 元数据/网络问题：放开所有broker的访问权限，同时调整topic.metadata.refresh.interval.ms=30000加快元数据刷新频率。
• 固定key导致的问题：如果业务不需要消息按key有序，可调整分区器为轮询模式，或发送无key消息实现负载均衡。

内容的提问来源于stack exchange，提问作者Abid Zaidi