适用场景

消息队列的价值是解耦与削峰，风险是积压：消费慢了没人发现，磁盘写满后整个链路停摆。

配置步骤（可靠性与幂等设计）

# 生产端：acks=all / 同步发送（按业务）
# 消费端：手动提交位点，处理成功再提交
# 幂等：消息带唯一业务 ID，消费端去重表
# 顺序：同一 key 落到同一分区

关键参数与建议

  • 集群规划：分区数按吞吐与并发消费者数设计，避免过多分区拖慢元数据
  • 副本与可靠性：至少 2~3 副本，生产端 acks 与消费端手动提交按业务选择
  • 积压监控：Lag 监控与告警，设置消费延迟阈值
  • 磁盘与保留：按流量计算保留策略，避免磁盘写满
  • 幂等与顺序：业务侧要能处理重复消息，顺序消息需按 key 分区

容易踩的坑

  • 生产端 acks=0，Broker 故障丢消息
  • 消费端自动提交，处理失败消息丢失
  • 无幂等设计，重复消费导致数据错乱

验证与巡检

# 验证：模拟重复消息与消费者重启，确认无重复入库
  • 巡检：幂等记录表、位点提交策略、可靠性压测

小结

消息队列的验收：压测达标、积压能告警、消费者扩容有效、磁盘有保护策略。四条缺一条，早晚出事。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。