新功能发布记录
Broker 版本升级记录
公告
客户端生产消息时延高
问题现象
客户端现象表现为 Producer 消息发送时延增加：
消息写入速度变慢，发送时延增大。
CPU 使用率过高。
排查步骤
步骤1：限流检查
检查单个 Topic 是否被限流：如果限流值，会导致消息发送速率受限。
优化建议：增加 Topic 限流值（基于实际业务需求）。
检查实例是否限流。如果出现限流，需要增加带宽。
步骤2：集群性能检查
检查集群 CPU 负载，如果是集群整体负载高，直接导致发送时延升高。
优化方案：扩容
步骤3：客户端参数优化
合理设置批量参数，减少碎片化请求，提升发送性能。 小批次（小 Batch）会导致客户端频繁发起请求，增加服务端排队压力，进而推高延迟和 CPU 消耗。
优化建议：
合理设置 acks \\batch.size 和 linger.ms，结合业务需求调整参数，推荐值：
acks=1batch.size=16384linger.ms=1000
详细解释如下：
1. ack 参数调整
Acks 参数控制了 Producer 发送消息后等待的确认机制：
acks=0：无需服务端确认，性能较高，但丢数据风险大。
acks=1：主节点写成功即返回确认，性能中等，适合大多数场景。
acks=all 或 -1：主节点和副本均写成功后返回确认，数据可靠性高，但性能较差。
优化建议：
为提升发送性能，建议设置
acks=1。2. 调整批次发送参数
批量发送可以减少请求次数，提高网络吞吐量：
batch.size：每个分区缓存的消息总大小（单位：字节）。当达到设置值时，触发批量发送。
linger.ms：消息在缓存中停留的最长时间，超过该值后会立即发送，即使未达到
batch.size。推荐配置：
batch.size=16384（默认值：16KB）。linger.ms=1000（默认值：0，即不等待直接发送）。3. 调整缓存大小
buffer.memory：控制缓存消息的总体大小。缓存超限时会强制触发发送，忽略
batch.size 和linger.ms。默认值为 32MB，对于单个 Producer 而言，可以保证足够的性能。
建议配置：
buffer.memory ≧ batch.size * 分区数 * 2。注意：
如果在同一 JVM 中启动多个 Producer，请谨慎设置
buffer.memory，避免 OOM 问题。关键问题
1. CPU 高负载的原因
Kafka CPU 的高负载通常来自以下几个方面：
生产和消费请求处理：
高吞吐量的 Producer 和 Consumer 会占用大量 CPU
数据复制：
副本同步的过程需要进行数据复制操作
高频控制请求：
例如 Offset 管理、Metadata 查询等高频操作，会占用 Broker 的 CPU 资源。
2. 如何处理集群高负载
集群高负载的常见表现包括：
消息发送延迟增加。
请求队列深度过大，持久维持在高位。
Broker 的 CPU 或磁盘 I/O 持续高负载。
解决方法：
2.1 扩容：
增加 Broker 节点数，平摊分区负载，减轻单台服务器压力。
优化分区分布，确保分区均匀分布在所有 Broker 上。
2.2 限流：
设置合理的生产限流值，避免生产端流量暴增导致 Broker 超载。
3. 集群高负载情况，如何优化客户端实现低延迟
当 Kafka 集群无法扩容或负载无法有效降低时，可以优化客户端配置以尽量获取低延迟。
参考 客户端参数优化
合理设置
acks \\batch.size 和 linger.ms，结合业务需求调整参数，推荐值：acks=1batch.size=16384linger.ms=1000
总结
通过以上排查步骤和参数优化方法，可以有效解决 Kafka 集群负载高和生产消息时延高的问题。
对于集群负载高的情况，扩容是最直接的解决方案；
对于客户端参数优化，调整批次发送和缓存大小可以显著提高性能。
文档反馈