从Apache Kafka 2.3.1升级至2.5.1后代理延迟大幅升高

以下是针对该性能异常的核心原因分析，结合Kafka版本特性与测试场景逐一说明：

1. Broker端acks=all处理逻辑的已知bug（KAFKA-10875） #

Kafka 2.5.0和2.5.1版本存在一个影响acks=all场景的性能缺陷：当生产者要求所有副本确认消息时，Broker端的请求处理逻辑出现阻塞，导致等待副本确认的时间大幅增加，直接拉高了生产者的平均延迟。该问题已在Kafka 2.5.2及后续版本中修复。

2. 生产者重试机制的累积延迟 #

虽然Kafka 2.3.1和2.5.1的retries默认值均为2147483647（无限重试），但2.5.1版本将delivery.timeout.ms的默认值从120000ms（2分钟）降至30000ms（30秒）。若测试过程中出现短暂的副本同步延迟（即使硬件性能足够，也可能因JVM GC、网络瞬时抖动触发），生产者会触发重试，而retry.backoff.ms默认100ms的等待时间会累积到平均延迟中，导致整体延迟飙升。

3. Topic副本配置不匹配 #

如果测试使用的test_topic是自动创建的，Kafka默认default.replication.factor为1。此时acks=all仅需leader节点确认，理论延迟应较低，但如果升级后Broker端的min.insync.replicas被修改为大于1的值，会导致生产者因无法获得足够的同步副本确认而阻塞，大幅增加延迟。需结合Topic的实际配置验证该场景。

验证与修复建议 #

• 优先升级到Kafka 2.5.2或更高版本，修复acks=all场景的性能bug；
• 检查test_topic的副本数和min.insync.replicas配置，确保与3节点集群匹配（建议副本数设为3，min.insync.replicas设为2）；
• 临时调整生产者参数：设置retries=0（仅用于测试，生产环境不建议）或增加delivery.timeout.ms，观察延迟是否恢复，以排查重试机制的影响；
• 监控Broker端的UnderReplicatedPartitions指标，确认是否存在副本同步异常。

内容的提问来源于stack exchange，提问作者remigiusz boguszewicz