fetch.max.bytes 是提升 Kafka 消费者拉取性能最见效的手段之一，通过控制单次 fetch 请求最大字节数（默认50MB，建议50MB～100MB）实现满载拉取，比 max.poll.records 更底层稳定。
直接调 Fetch 缓存参数是提升 Kafka 消费者拉取性能最见效的手段之一。关键不是堆参数，而是让每次 fetch 请求尽可能“满载而归”，同时避免空等或超时中断。
用 fetch.max.bytes 控制单次拉取总量
这个参数设定了消费者一次 fetch 请求能拿到的最大字节数，直接影响网络利用率和吞吐量。它比 max.poll.records 更底层、更稳定——尤其当消息大小不均时，按字节限制比按条数限制更可靠。
- 默认值是 50MB，生产环境建议设为 50MB～100MB（取决于网络带宽和 Broker 负载）
- 如果消息普遍偏大（比如含图片 Base64），可适当提高；若消息都很小（
- 注意：该值不能超过 Broker 的
message.max.bytes和replica.fetch.max.bytes，否则请求会被拒绝
靠 fetch.min.bytes + fetch.max.wait.ms 减少空拉取
这两个参数配合使用，本质是“等够量再给，但别等太久”。目的是避免频繁发小包请求，降低网络开销和 Broker 压力。
- fetch.min.bytes：Broker 至少攒够这么多字节才返回响应。推荐设为 1MB～5MB（太小起不到合并效果，太大导致延迟升高）
- fetch.max.wait.ms：即使没攒够 min.bytes，最多等这么久也必须返回。推荐值 300～500ms（高吞吐场景），低延迟场景可压到 50～100ms
- 举例：设 min=2MB、wait=400ms，意味着 Broker 会等最多 400ms，只要数据达到 2MB 就立刻返回；若 400ms 到了还没攒够，也会把已有的数据发回来
用 max.partition.fetch.bytes 防止单分区吃光内存
即使总字节数可控，如果某个分区消息特别密集（比如热点 key 导致数据倾斜），仍可能把 consumer 内存打爆。这个参数就是给每个分区单独设上限。
立即学习“Java免费学习笔记（深入）”；
- 默认 1MB，建议根据实际消息平均大小调整为 5MB～10MB
- 设得太小会导致该分区频繁 fetch 多次才能取完一批，增加延迟；设太大则可能引发 OOM
- 配合
max.poll.records使用更稳妥：比如设 max.poll.records=500，单条消息平均 2KB，则理论最大内存占用 ≈ 500×2KB ≈ 1MB —— 此时 max.partition.fetch.bytes 可设为 2～3MB 留出余量
配合 max.poll.records 避免处理阻塞
它不直接控制 fetch，但决定 poll() 返回多少条记录交给业务线程处理。如果设得过大，单次处理时间过长，可能触发心跳超时（session.timeout.ms），引发不必要的 rebalance。
- 高吞吐场景：设为 500～1000，配合较大的 fetch.max.bytes 使用
- 低延迟或业务处理重的场景：设为 10～100，确保 poll 后能快速完成处理并发送 heartbeat
- 注意：它只是“上限”，实际返回条数由 fetch 结果决定；真正起作用的是 fetch 参数组合
