如何保证消息不丢失？
简化版
消息从生产到消费要经过三个环节，每个环节都可能丢消息，所以要三端都保证：① 生产端——用同步发送 + 确认机制（如 RocketMQ 的 SYNC 发送、Kafka 的 acks=all），发送失败重试；② 存储端（Broker）——消息持久化到磁盘、多副本同步（主从复制），防止 Broker 宕机丢消息；③ 消费端——处理完成后再手动 ACK（而不是收到就自动确认），保证消息真正被处理，中途失败可重新投递。三端环环相扣，任何一端不到位都会丢消息。
详细版
三个可能丢消息的环节：
① 生产者 → Broker（发送丢失）：网络问题导致消息没到 Broker，或 Broker 收到还没持久化就宕机。
- 解决：同步发送 + 确认。生产者发消息后等待 Broker 的确认响应（ack），收到才算成功，没收到就重试。Kafka 设
acks=all（等所有 ISR 副本确认）、RocketMQ 用同步发送。
② Broker 存储（存储丢失）：Broker 把消息只放在内存，还没落盘就宕机；或只存了一个副本，那台机器磁盘坏了。
- 解决：持久化 + 多副本。消息刷盘到磁盘（同步刷盘更可靠但慢，异步刷盘快但极端情况可能丢一点）；主从复制，多个副本，主挂了从顶上。
③ Broker → 消费者（消费丢失）：消费者收到消息，还没处理完（或处理失败）就自动 ACK 了，Broker 以为处理成功删了消息，实际没处理。
- 解决：手动 ACK。关闭自动确认，消费者业务处理成功后才手动 ACK；处理失败不 ACK，消息会被重新投递。
完整版教学
一、丢消息的三个环节，一个都不能漏
消息的一生：生产者产生 → 发到 Broker → Broker 存储 → 投递给消费者 → 消费者处理。丢消息可能发生在任何一个交接环节。所以「保证消息不丢」不是一个单点措施，而是要三端协同——生产端保证「发出去且确认到达」，存储端保证「存住不丢」，消费端保证「处理完才确认」。任何一端偷懒，整条链路就有丢消息的风险。面试要分三端答，才完整。
二、生产端：同步发送 + 确认 + 重试
生产者发消息可能因为网络抖动没到 Broker。防丢的关键是要有确认：
- 别用「发完不管」的方式（如 Kafka 的
acks=0或异步发送不处理回调）——发出去就不知道到没到。 - 用同步发送 + 等确认：发送后等待 Broker 返回 ack，收到才算成功。RocketMQ 的
send()同步方法、Kafka 的acks=all（等所有同步副本确认，最可靠）。 - 失败重试：没收到确认就重试几次。注意重试可能导致消息重复（Broker 其实收到了只是 ack 丢了），所以要配合消费端幂等。
acks 的取舍：acks=0（不等确认，最快最不可靠）、acks=1（等主副本确认，主挂可能丢）、acks=all（等所有 ISR 副本确认，最可靠但最慢）。要不丢消息用 acks=all。
三、存储端：持久化 + 多副本
消息到了 Broker，也可能丢：
- 没落盘就宕机：Broker 为了性能，可能先把消息放内存、稍后批量刷盘（异步刷盘）。如果刷盘前宕机，内存里的消息就丢了。同步刷盘（每条消息都刷到磁盘才返回）最可靠，但慢；异步刷盘快，但极端宕机会丢一小段。按可靠性要求选。
- 单副本磁盘坏：只有一份存储，那台机器磁盘损坏就彻底丢了。多副本（主从复制）解决——消息同步到多个副本，一台坏了其他副本还在。Kafka 的 ISR 机制、RocketMQ 的主从同步复制（
SYNC_MASTER）保证消息在多个节点都有。
所以存储端防丢 = 持久化到磁盘（防内存丢）+ 多副本（防单机磁盘坏）。
记忆点：三端防丢——生产端「同步发送+确认+重试」（
acks=all）、存储端「持久化刷盘+多副本」、消费端「处理完再手动 ACK」。三端环环相扣，漏一端就丢。
四、消费端：处理成功后再手动 ACK
消费端最容易丢消息的错误是**「自动 ACK」：消费者一收到消息，MQ 客户端就自动确认（ack），然后 Broker 认为投递成功、删除消息。但如果消费者收到后、处理完成前就崩溃了**（或处理抛异常），这条消息实际没被处理，却已经被确认删除——丢了。
正确做法是手动 ACK：关闭自动确认，消费者在业务逻辑真正执行成功后，才手动发送 ACK。如果处理失败或消费者崩溃，没有 ACK，Broker 会认为这条消息没消费成功，重新投递（给这个消费者重试，或给别的消费者）。这样保证「消息一定被成功处理过才算完」。代价是：重新投递会导致重复消费，所以消费端必须幂等（见「消息不重复」专题）。
五、可靠性和性能的权衡
保证不丢消息是有代价的——每一层的可靠措施都牺牲性能：同步发送比异步慢、acks=all 比 acks=1 慢、同步刷盘比异步刷盘慢、多副本同步复制比单副本慢。所以要按业务重要性选择可靠级别：金融交易消息要「一个都不能丢」，就全套最高可靠（同步发送 + acks=all + 同步刷盘 + 同步多副本 + 手动 ACK）；日志、埋点这类允许丢一点点的，可以放松换取吞吐（异步发送、异步刷盘）。不要无脑全上最高可靠，会严重拖累性能。
六、常见误区与追问
这道题不能只背概念，要把「消息不丢失」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 消息不丢失要覆盖生产者确认、Broker 持久化和多副本、消费者手动 ack 三段链路 | 不要停在名词解释 |
| 流程机制 | 生产者发送并等待确认 -> Broker 写入磁盘和副本 -> 消费者拉取处理 -> 业务成功后提交 offset 或 ack -> 失败重试和补偿扫描 | 说明触发方、存储方、确认点和兜底 |
| 工程取舍 | Kafka 生产端 acks=all 且 min.insync.replicas=2 时，至少多个 ISR 副本确认后才算写入成功 | MQ 解耦削峰但带来最终一致、重复消费和可观测性要求 |
消息不丢失 面试拆解：
1. 生产者发送并等待确认
2. Broker 写入磁盘和副本
3. 消费者拉取处理
4. 业务成功后提交 offset 或 ack
5. 失败重试和补偿扫描记忆钩子：先拆生产者、Broker、消费者、offset、重试和幂等，再说明丢失、重复、顺序和积压边界；回答时要紧扣「消息不丢失」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：发送成功就代表消息不会丢。 还要看 Broker 是否持久化、副本是否同步、消费者是否正确 ack。
- 误区：自动提交 offset 最安全。 自动提交可能在业务处理前提交，宕机后消息丢处理。
- 误区：只要持久化就不需要监控。 磁盘满、副本落后、ISR 缩小都会影响可靠性。
- 追问：生产端怎么保证？ 同步发送、确认回调、重试和本地消息表。
- 追问：Broker 端怎么保证？ 持久化、多副本、刷盘策略和 ISR 约束。
- 追问：消费端怎么保证？ 业务成功后 ack/提交 offset，失败不提交并重试。
七、加强记忆
保证消息不丢要三端协同：① 生产端——同步发送 + 等 Broker 确认 + 失败重试（Kafka acks=all 等所有 ISR 副本确认最可靠）；② 存储端——消息持久化刷盘（防内存丢，同步刷盘最可靠）+ 多副本主从复制（防单机磁盘坏）；③ 消费端——关闭自动 ACK，业务处理成功后才手动 ACK，失败不 ACK 则重新投递。三端环环相扣，漏一端就丢。代价是各层可靠措施都牺牲性能，要按业务重要性权衡；重试和重投会导致重复，需配合消费幂等。