消息队列如何保证消息不丢失？
简化版
消息从生产到消费要经过三个阶段，每个阶段都可能丢，要各自保证：① 生产阶段——生产者发消息后要拿到 Broker 的确认（ACK），失败则重试；② 存储阶段——Broker 要把消息持久化到磁盘、并通过多副本（主从/ISR）防止单机故障丢失；③ 消费阶段——消费者要处理成功后再手动 ACK（而不是收到就自动确认），处理失败不 ACK 则消息会被重投。三个阶段全部做到位，才能端到端不丢消息。
详细版
三个阶段的丢失点与对策：
| 阶段 | 丢失场景 | 解决方案 |
|---|---|---|
| 生产 | 消息没发到 Broker（网络问题） | 同步发送 + 等 ACK，失败重试；用事务/confirm 机制 |
| 存储 | Broker 收到但没落盘就宕机；主节点挂了副本没同步 | 持久化刷盘 + 多副本同步（如 Kafka acks=all、RocketMQ 同步刷盘+同步复制） |
| 消费 | 消费者收到消息还没处理完就宕机，消息却已被确认 | 手动 ACK：处理成功才确认；关闭自动 ACK |
Kafka 的关键配置（防丢）：
- 生产者：
acks=all（等所有 ISR 副本确认）、retries>0（失败重试）。 - Broker：
replication.factor>=3（多副本）、min.insync.replicas>=2（至少 2 个副本同步成功）。 - 消费者：
enable.auto.commit=false（关闭自动提交 offset），处理完再手动提交。
完整版教学
一、先建立”三阶段”模型
要回答「消息不丢」，必须先把消息的生命周期拆成三段，因为每一段都是独立的丢失点，任何一段没做好都会丢：
生产者 --①生产--> Broker --②存储--> Broker --③消费--> 消费者- ①生产阶段：消息从生产者到 Broker 的路上丢（没发出去/网络丢包）。
- ②存储阶段：消息到了 Broker，但 Broker 还没安全存下来就出事（没落盘、单机宕机、副本没同步）。
- ③消费阶段：Broker 把消息给了消费者，但消费者没处理完就宕机，消息却被标记为「已消费」丢了。
端到端不丢 = 三个阶段各自都不丢。面试要分三段答，才完整。
二、生产阶段：确认 + 重试
生产者发消息到 Broker，网络可能失败、Broker 可能没收到。保证不丢的关键是别用「发了就不管」的方式，而要等 Broker 确认（ACK）：
- 同步发送 + 等待 ACK：发送后阻塞等待 Broker 返回确认，收到 ACK 才算成功；没收到（超时/失败）就重试。
- Kafka：设
acks=all（要求 Leader 和所有同步副本都确认）+retries设大于 0（自动重试）。 - RocketMQ：用同步发送（
send()返回SEND_OK），失败重试。 - 事务消息：更强的保证，确保「本地业务 + 发消息」的原子性（另有专题）。
注意重试可能导致消息重复（发了但 ACK 丢了，重发一次），所以要配合消费端幂等——这是「不丢」和「不重」的权衡：宁可重复，不可丢失。
三、存储阶段：持久化 + 多副本
消息到了 Broker，如果 Broker 只放在内存里、还没写磁盘就宕机，消息就丢了。即使写了磁盘，如果这台机器彻底坏了、又没有副本，数据也没了。所以存储阶段要两条保证：
① 持久化刷盘。 Broker 收到消息要写入磁盘（而非只在内存）。刷盘又分：
- 同步刷盘：写入磁盘成功才返回 ACK，最安全但慢（RocketMQ
SYNC_FLUSH）。 - 异步刷盘：先返回 ACK、后台异步刷盘，快但宕机可能丢刚收到的少量消息（
ASYNC_FLUSH）。
② 多副本冗余。 单机再可靠也怕整机故障，要把消息复制到多个节点：
- Kafka：
replication.factor>=3（每个分区 3 个副本），min.insync.replicas>=2（至少 2 个副本同步成功才算写入成功，配合acks=all）。这样即使 Leader 挂了，从 ISR 中的副本还能恢复数据。 - RocketMQ：主从同步复制（
SYNC_MASTER），主节点等从节点同步成功才返回。
同步复制 + 同步刷盘最安全但性能低，异步则快但有丢失风险——按业务对可靠性的要求权衡。
四、消费阶段：手动 ACK，处理成功再确认
最容易被忽视的丢失点在消费端。如果消费者一收到消息就自动确认（auto-commit），然后才去处理，那么「确认了但处理到一半宕机」时，这条消息已被标记为「已消费」、不会再投递，处理逻辑没跑完就丢了。
正确做法：关闭自动确认，改为手动 ACK——业务处理成功之后才确认：
- Kafka：
enable.auto.commit=false，处理完消息后手动commitSync()提交 offset。这样处理没完成就宕机，offset 没提交，重启后会重新消费这条消息（可能重复，需幂等）。 - RabbitMQ：手动
basicAck，处理成功才 ack；失败basicNack重新入队。 - RocketMQ：消费成功返回
CONSUME_SUCCESS,失败返回RECONSUME_LATER触发重试。
核心原则：先处理业务、后确认消息。确认的语义是「我已经安全处理完了」，而不是「我收到了」。
五、“不丢”的代价：重复与性能
追求「绝对不丢」是有代价的：
- 可能重复：生产重试、消费重投都可能导致消息被处理多次。所以「不丢」几乎总是伴随「可能重复」，必须配合消费端幂等（另有专题）。业界共识是**「至少一次投递（at-least-once）+ 消费幂等」**，而不是追求「恰好一次（exactly-once）」（后者代价极高）。
- 性能下降：同步发送、同步刷盘、同步多副本、手动 ACK 都比异步的慢。要根据业务对可靠性的要求做权衡——金融交易要最强保证，日志采集可以容忍少量丢失换取吞吐。
六、常见误区与追问
| 考点 | 正确口径 |
|---|---|
| 生产端 | 发送失败、未确认、异步缓冲丢失 |
| Broker | 未刷盘、无副本、Leader 故障 |
| 消费端 | 先提交 offset/ack 后处理失败 |
producer: retry + ack=all
broker: replication factor >= 3, min.insync.replicas >= 2
consumer: process success -> commit offset/ack防丢消息要沿链路看：生产者、Broker、消费者，任何一段先确认后落地都可能丢。
- 误区：MQ 天然保证绝不丢消息。 可靠性取决于生产确认、刷盘/复制、消费提交和配置。
- 误区：消费者收到消息就可以先提交 offset。 先提交后处理，一旦处理失败就会丢业务结果。
- 误区：只开重试就能防丢。 重试要配合幂等，否则可能把丢消息风险变成重复处理风险。
- 追问：Kafka 生产端如何提高可靠性？ 设置 acks=all、合理 retries、幂等生产者和足够 ISR。
- 追问：Broker 如何防单点丢失？ 使用多副本、同步复制、最小 ISR 和故障转移策略。
- 追问：消费端如何提交进度？ 业务处理成功并持久化后再 ack/commit offset。
七、加强记忆
消息不丢 = 生产、存储、消费三阶段各自不丢。①生产：发送后等 Broker 的 ACK，失败重试（Kafka acks=all+retries）；②存储：持久化刷盘（同步刷盘更稳）+ 多副本同步（Kafka replication.factor>=3、min.insync.replicas>=2；RocketMQ 同步复制），防单机故障；③消费：关闭自动 ACK，业务处理成功后再手动确认（先处理后确认，宕机则重投）。代价是可能重复（需配合幂等）和性能下降，业界走「至少一次 + 消费幂等」而非昂贵的「恰好一次」。口诀：生产要确认、存储要落盘多副本、消费要处理完再 ACK。