Kafka消费者稳定性与吞吐能力由max.poll.records和max.poll.interval.ms等参数协同决定：前者控制单次拉取条数（建议20～100或500～1000），后者设定两次poll最大间隔（建议2～10分钟）；需满足“单条平均处理时间×max.poll.records＜max.poll.interval.ms”，并合理配置session.timeout.ms（10～25秒）、heartbeat.interval.ms（≤session.timeout.ms/3）及fetch相关参数。
Kafka 消费者拉取记录数和超时参数直接决定消费稳定性与吞吐能力，配得不合理容易触发重平衡、消息堆积或重复消费。核心就两个方向：控制单次拉多少（量），以及拉完后多久必须处理完并再次 poll（时间窗口）。
控制单次拉取条数：max.poll.records
这个参数限制每次 poll() 调用最多返回多少条消息，默认是 500。它不是越大越好——拉太多，单次处理时间容易超限；太小，又浪费网络和轮询开销。
- 若业务逻辑简单（如日志打点、字段转换），可设为 500～1000，提升吞吐
- 若每条消息需调用外部 API 或写 DB，建议压到 20～100，避免单次处理耗时过长
- 必须确保：单条平均处理时间 ×
max.poll.records＜max.poll.interval.ms，否则会因未及时 poll 而被踢出组
关键超时三件套：max.poll.interval.ms、session.timeout.ms、heartbeat.interval.ms
这三个参数协同工作，共同防止消费者“假死”引发重平衡。
-
max.poll.interval.ms：两次
poll()的最大间隔。默认 30 秒。如果上一次 poll 后，你的代码花了 35 秒才开始下一次 poll，Kafka 就认为你挂了，立即触发重平衡。建议根据实际处理耗时设为 2～10 分钟（如 600000 毫秒） - session.timeout.ms：消费者心跳会话超时。默认 10 秒。代表协调器等待心跳的最大空闲时间。生产环境建议设为 10000～25000（10～25 秒），太短易误判，太长故障发现慢
-
heartbeat.interval.ms：心跳发送频率。必须小于
session.timeout.ms的 1/3（比如 session 设 15 秒，heartbeat 最好 ≤ 5000）。常用值是 3000 毫秒
自动提交偏移量的配套设置
如果开启自动提交（enable.auto.commit=true），还要注意：
-
auto.commit.interval.ms控制提交频率，默认 5000 毫秒。频率太高增加 Kafka 压力，太低可能重复消费 - 更推荐关闭自动提交（
enable.auto.commit=false），在业务处理成功后再手动调用commitSync()或commitAsync()，确保偏移量提交与业务结果强一致
配合使用的 fetch 相关参数
虽然不直接叫“超时”，但它们影响实际拉取行为和延迟表现：
-
fetch.min.bytes：Broker 至少攒够这么多字节才响应，避免空转。低流量场景可设为 10240（10KB）以上 -
fetch.max.wait.ms：Broker 最多等多久，即使没攒够fetch.min.bytes也返回。默认 500 毫秒，对延迟敏感可调低至 100 毫秒 -
request.timeout.ms：客户端发起请求后的总超时（含网络+服务端处理），建议 ≥max.poll.interval.ms+ 5 秒，防止请求卡住阻塞整个消费循环
