消息队列如何保证消息不丢失，生产端和消费端各做哪些保障？

核心回答

消息可靠性要覆盖生产、队列存储、消费处理整条链路。生产端确认发送结果，对失败或结果未知的发送做可恢复重试；Broker 通过持久化、副本和故障切换保护已接收消息；消费端在业务处理成功后再确认，并用业务幂等处理重投。

可靠性有故障假设：所有副本同时永久丢失、消息已过保留期等情况仍可能造成损失。更准确的目标是，在约定故障范围内可恢复、可对账，而不是只设置一个参数就承诺绝不丢失。

各环节怎样兜底

生产端先把业务事件可靠记录下来。若数据库提交与发消息需要衔接，可以采用事务发件箱：业务记录和待发事件一起提交，再由发送器确认并补发。只在内存记“待发送”会在进程退出时丢失。

RabbitMQ 的 publisher confirm 只证明生产者与 Broker 一侧的接收，不代表消费者已完成业务；还需处理无法路由的消息，并结合合适的持久化队列类型与消息属性。Kafka 则需共同考虑副本数、ISR、acks 和最小同步副本数，发送确认也不是整个业务链的成功标志。

消费端先提交业务结果，再发送 ack 或提交 offset。若处理完成后、确认前宕机，消息会重来，业务唯一键、去重表或状态机应保证只产生一次效果；反过来先确认再处理，则宕机会形成业务漏处理。

追问

• 失败消息怎么办？ 区分暂时失败和不可处理消息，有限退避重试；进入死信或失败任务后继续告警、对账和补偿，不能把转入死信当作业务成功。
• Exactly once 是否覆盖 MySQL？ Kafka 内部事务可协调输入位点与输出 Topic，但外部数据库还需参与协调，或把消费进度和业务结果放进同一个事务；不能直接外推。
• 怎样验证？ 在发送确认前后、业务提交前后和位点提交前后终止实例，检查最终业务效果和待补偿记录，同时监控积压、重投及发送失败。

参考资料