消息中间件最怕两个问题:丢了和重了。本文从 Producer、Broker、Consumer 三个角度给出完整的可靠性设计方案。

一、消息可靠性的三端模型

  • 1.1 Producer → Broker → Consumer 的传递链路
  • 1.2 每一端都有丢失的可能
  • 1.3 “至少一次” vs “最多一次” vs “精确一次”

二、Producer 端——保证发送不丢失

  • 2.1 acks = -1(all)——所有 ISR 副本确认
  • 2.2 retries 重试机制——网络抖动导致临时失败
  • 2.3 max.in.flight.requests.per.connection——重试引发乱序
  • 2.4 enable.idempotence = true——幂等生产者
  • 2.5 幂等原理——Producer ID + Sequence Number

三、Broker 端——保证存储不丢失

  • 3.1 replication.factor ≥ 3
  • 3.2 min.insync.replicas ≥ 2
  • 3.3 unclean.leader.election.enable = false——禁止不在 ISR 的副本竞选
  • 3.4 log.flush.interval.messages——刷盘的权衡

四、Consumer 端——保证消费不丢失

  • 4.1 enable.auto.commit = false——手动提交
  • 4.2 先处理业务再提交 offset
  • 4.3 commitSync() vs commitAsync() 的选择
  • 4.4 幂等消费——业务表唯一键去重

五、精确一次语义(Exactly Once)

  • 5.1 Kafka Streams 的精确一次
  • 5.2 事务消息——read_committed 隔离级别
  • 5.3 事务原理——Transaction Coordinator
  • 5.4 事务的性能代价

六、消息重复的常见场景与处理

  • 6.1 生产者重试导致重复
  • 6.2 消费者 rebalance 导致重复
  • 6.3 幂等去重的 5 种方式——数据库唯一键、Redis Set、布隆过滤器等

七、监控关键指标

  • 7.1 records-lag-max——消费延迟
  • 7.2 消息丢失率推算
  • 7.3 关键告警配置

八、总结

  • 可靠性配置清单(checklist)
  • 在可靠性和性能之间如何权衡