消费性能由两组参数决定
消费端性能分两段：拉取段决定一次从 broker 取多少数据、最多等多久，处理段决定应用一次处理多少条、允许处理多长时间。拉取参数偏小会让每个请求都很空、请求次数偏多；max.poll.records 偏大又会让单批处理时间变长，一旦超过 max.poll.interval.ms 就会被踢出消费组并触发重平衡。调优本质是把这两段参数匹配起来。
基本信息
| 拉取参数 | fetch.min.bytes（默认 1）、fetch.max.wait.ms（默认 500） |
|---|---|
| 处理参数 | max.poll.records（默认 500）、max.poll.interval.ms（默认 300000） |
| 内存相关 | max.partition.fetch.bytes（默认 1MB） |
| 版本差异 | Kafka 3.0 起 session.timeout.ms 默认 45000，心跳由客户端后台线程维持 |
典型使用场景
- 消费积压但 CPU 不吃紧：适度调大批次，减少拉取与位移提交次数
- 延迟敏感链路：调小 fetch.max.wait.ms，避免等待凑批
- 单批处理慢的业务（如逐条调用外部接口）：放大 max.poll.interval.ms 防止被踢
- 下游写入压力大：调小 max.poll.records，控制单批写入量
- 实例多于分区：先解决并行度问题，再谈参数调优
批量消费配置
批量消费配置
fetch.min.bytes=1048576 # 至少凑满 1MB 再返回，减少空拉取
fetch.max.wait.ms=500 # 最多等 500ms 就返回，避免高流量下延迟过大
max.poll.records=1000 # 单次 poll 返回的最大记录数
max.poll.interval.ms=600000 # 单批处理允许的最长时间，必须大于最慢批次耗时
max.partition.fetch.bytes=1048576参数与影响
| 参数 | 调大后的效果 | 主要风险 |
|---|---|---|
| fetch.min.bytes | 批量更满，吞吐提升 | 低流量分区延迟上升 |
| max.poll.records | 单批吞吐提升 | 处理超时被踢出消费组 |
| max.poll.interval.ms | 容忍更慢的处理 | 故障检测变迟钝 |
| max.partition.fetch.bytes | 单分区单次拉取更多 | 内存占用上升 |
| session.timeout.ms | 容忍更长的网络抖动 | 故障发现变慢 |
调大 max.poll.records 提升吞吐是常见做法，但要同步评估单批处理时间与 max.poll.interval.ms 的关系，两者不匹配会周期性触发重平衡，表现为消费反复停顿。
fetch.min.bytes 设置过大时，低流量分区要等凑满字节数或等到超时才返回，实时性要求高的链路反而会变慢，调大前先确认流量特征。