发布日期:
2026-01-18
更新日期:
2026-09-17
文章字数:
523
阅读次数:
一、Producer端
batch.size：批量发送消息大小（默认16kb）。Producer会将消息先缓存到本地，达到阈值后才发送（合理调大该配置可以减少网络IO，也不能太大，不然反而导致内存占用过高/网络时延高）linger.ms：批量发送延迟（默认0ms）。即使batch.size未达到阈值，如果等待超过该时间也会发送compression.type：消息压缩类型（默认none，不压缩）。数据比较大时可以考虑设置成gzip或snappy压缩消息，减少网络贷款，提升吞吐量acks：消息确认机制（默认1）
1：Leader写入成功即可（适用大多数业务，吞吐量与可靠性平衡）0：不需要确认（适用非核心数据，如日志埋点）-1/all：Leader+ISR全部写入成功（适用核心数据，如交易订单）
二、Consumer端
fetch.min.bytes：拉取消息的最小数据量（默认1b）。增大这个值可以每次获取更多数据，减少请求次数（网络IO）fetch.max.wait.ms：拉取超时时间（默认500ms）。适当减少该值可以提高消费效率session.timeout.ms：会话超时时间（默认10000ms）。配合heartbeat.interval.ms心跳配置，如果超时未发送心跳，broker则会认为该Consumer不可用，从而触发重平衡enable.auto.commit：是否自动提交偏移量
true（默认）：自动提交偏移量，如果提交完但消息未处理完，则会丢失消息false：手动提交偏移量，适合核心业务（如支付订单）
三、总结：优化核心原则
- 吞吐量与延迟权衡：增加批量大小+压缩=提升吞吐量+增加延迟，反之亦然
- 可靠性与性能权衡：
acks=-1虽然可以保证数据不会丢失，但性能却很差（因为需要同步所有ISR），反之亦然
- 合理分区数：适当增大分区数可以提高消息处理的并行度，具体需要根据Consumer实例数来决定（一般为Consumer实例数的2倍左右）
