Fetch 策略：Consumer 一次拉多少消息

验证：默认配置下，一有数据consumer真实立刻能拿到

命令 · python c1 = Consumer({"fetch.min.bytes": 1, "fetch.wait.max.ms": 500}) # producer真实每0.5秒发一条几字节的小消息

真实实测 · 本机执行输出

真实等待时间: 0.536s, 拿到: tiny-3

fetch.min.bytes=1真实意味着"只要有至少1字节的新数据，立刻返回"——broker端一收到这条消息，几乎马上就能把它交给consumer，真实等待时间基本等于消息真正到达的时间点，跟生产节奏(0.5秒一条)对得上。

验证：要求凑够1MB才返回，同样的小消息真实拖到了超时

命令 · python c2 = Consumer({"fetch.min.bytes": 1048576, "fetch.wait.max.ms": 3000})

真实实测 · 本机执行输出

真实等待时间: 3.173s, 拿到: tiny-4

这条小消息几个字节都不到，永远真实凑不够1MB，所以broker真实不会提前返回——但也不会无限期地等下去：fetch.wait.max.ms真实是这份等待的上限，3秒一到，broker就把手头有的这一点数据(哪怕远不到1MB)真实塞给consumer。真实观测到的3.173秒，跟配置的3000毫秒对得上(多出的173毫秒是网络往返和客户端轮询间隔)。这两个参数真实是一对博弈：fetch.min.bytes大能减少请求次数(攒够了再发一次大的)，但会真实增加延迟上限；fetch.wait.max.ms则是给这份延迟真实兜底，避免数据稀疏时consumer被无限期晾着。

分步演示：两种fetch配置真实的等待时间

每一步都是本文上面用两种fetch.min.bytes配置跑出来的原始结果。

凑批门槛和等待上限，谁先满足谁说了算

这一步新验证的配置

参考与说明

数据来自本机3节点Kafka 4.3.1集群，topic fetch-demo，producer以0.5秒/条的节奏持续写入。
没有验证：max.partition.fetch.bytes和fetch.max.bytes这两个"上限"参数真实的限流效果；高吞吐场景下fetch.min.bytes调大真实带来的请求数量下降幅度。

下一篇 · KAFKA 内部原理 58

Consumer Lag 到底怎么算