Kafka消息大小对传输速度的影响及消费延迟相关因素咨询

• 服务端侧
  • 硬件资源：磁盘IO性能、网络带宽是高吞吐场景下的核心瓶颈，机械盘的随机读写、带宽打满都会直接抬高延迟，高吞吐场景优先使用SSD+万兆网卡的配置。
  • 副本与ISR配置：副本数越多，副本同步耗时越长；ISR列表频繁波动、副本同步滞后时，如果配置了acks=all，生产端会等待所有同步副本写入完成才收到确认，同时消费端拉取消息也可能等待副本同步完成，延迟明显上升。
  • 服务端参数配置：replica.lag.time.max.ms设置过小会导致副本频繁踢出ISR，log.segment.bytes设置过小会导致日志段频繁滚动，都会额外增加服务端处理开销，抬高消费延迟。
  • 分区负载不均：少数分区承载远高于平均水平的流量，会导致对应消费实例压力过载，拖慢整个消费组的消费进度。
• 消费端侧
  • 消费并行度配置：消费线程数少于分区数时，无法充分利用分区的并行消费能力；线程数过多会导致线程上下文切换开销激增，反而增加延迟。
  • 消费逻辑性能：消费逻辑包含慢IO（同步调用数据库、第三方接口）、重计算操作时，单条消息处理耗时过长，会直接导致消费位点提交滞后，累积延迟。
  • 消费端参数配置：fetch.min.bytes设置过大，消费端会等待服务端攒够足够多的消息才返回，增加端到端延迟；max.poll.records设置过大，单次拉取的消息无法在max.poll.interval.ms内处理完，会触发消费组重平衡。
  • 消费组重平衡：消费实例上下线、订阅主题变更、消费耗时超过阈值都会触发重平衡，重平衡期间整个消费组会暂停消费，直接产生延迟。

Kafka的传输速度和单条消息大小有明显的相关性，不同区间的消息表现差异极大：

• 小于1KB的小消息：
  单个消息的额外开销（消息头、批次元数据、网络请求头）占比极高，如果没有开启批量发送，大量小消息会导致单位时间内的请求数暴涨，服务端的网络、IO处理资源被大量无效开销占用，实际有效吞吐量极低，整体传输速度反而很慢。开启linger.ms、batch.size参数批量聚合小消息后，传输速度会有3~10倍的提升。
• 1KB~10KB的中等大小消息：
  这个区间是Kafka的最优吞吐区间，额外开销占比低，批量聚合效率高，磁盘顺序写入、网络传输的效率都能拉满，传输速度能达到峰值。
• 大于1MB的大消息：
  Kafka默认单消息最大限制为1MB，超出的消息会直接发送失败，就算调整message.max.bytes、replica.fetch.max.bytes等参数放开限制，大消息也会占满批次空间，无法批量聚合多条消息，单请求处理耗时变长，还容易导致网络拥塞、Broker端磁盘写入耗时增加，消费端拉取大消息时也需要更长的IO读取时间，整体传输速度会出现明显下降，同时还会抬高整个集群的请求处理延迟，影响其他主题的流量。不建议直接用Kafka传输大于10MB的消息，建议拆分成小消息或者将大消息存入对象存储，Kafka只传输对应的索引地址即可。

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