陆拾贰號1. 重启前先分清：你是哪一种重启？
做RocketMQ运维或者日常开发，绕不开一个问题：重启到底会不会丢消息。网上搜一圈，答案五花八门，有人说"我重启啥也没丢"，也有人说"重启一次丢了几万条"。其实两边说的都对，关键差在重启方式和场景。要搞清楚这个问题，得先给"重启"分个类。
这里有一个核心认知：RocketMQ重启的丢消息风险，90%不取决于重启动作本身，而是取决于你重启之前的数据落盘和同步状态。 换句话说，你按下重启键那一刻，消息在内存里还是已经落盘、在Master上还是已经同步到Slave，才是真正决定命运的东西。
常见的重启场景有这么几类：
- 优雅重启：用官方提供的
mqshutdown脚本或者kill发送 SIGTERM 信号，让Broker完成收尾流程后退出。这种重启你基本不用担心丢失，因为RocketMQ的ShutdownHook会触发很多清理动作，包括把内存里剩余数据刷到磁盘。 - 强制杀掉：
kill -9直接杀掉Broker进程。这种情况下，操作系统没给你任何机会执行清理逻辑，内存里还没落盘的数据就直接没了。 - 物理机断电/宕机/蓝屏：这是最极端的情况，连操作系统都没机会做任何处理，PageCache里还没写入磁盘的数据直接蒸发。
- 主从切换：Master挂了，Slave被选为新Master。这个时候丢不丢消息，完全看主从之间的同步方式是同步复制还是异步复制。
别急着往下看答案，先记住一句话：优雅重启大概率不丢，强制kill有风险，断电/宕机在默认配置下一定会丢，同步复制的集群比异步复制稳得多。 接下来我逐个拆开说透。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 消息到底存在哪里：CommitLog、ConsumeQueue与消息落盘的真相
要理解重启为什么可能丢消息，先得知道消息在RocketMQ内部是怎么流转的。很多初学者以为生产者把消息发到Broker，Broker存到磁盘，就万事大吉了。实际上远没那么简单。
2.1 消息的存储链路：从内存到磁盘的中间站
RocketMQ的消息存储以 CommitLog 为核心。所有消息到达Broker后，顺序写入CommitLog文件，然后由专门的ReputMessageService异步构建 ConsumeQueue（消费队列）和 IndexFile（索引文件）。这个设计非常巧妙——CommitLog是唯一的数据源，ConsumeQueue只是一层索引，用来加速消费端的消息拉取。
关键在于 写入CommitLog不等于持久化完成。消息先进入的是操作系统层面的PageCache（页缓存），也就是内存区域。写入PageCache后，Broker就会给生产者返回写入成功的响应。真正把PageCache里的数据刷到磁盘上，由两个异步线程负责：
FlushRealTimeService：定时刷盘线程，默认每500ms执行一次。CommitRealTimeService：负责将消息从堆内内存写入堆外内存，再由刷盘线程落盘。
这中间存在一个 时间窗口：消息已经写入CommitLog文件的内存映射区域，但还没被force到物理磁盘。如果在窗口期内进程崩溃或者机器断电，这条消息就丢了——虽然生产者已经收到了"写入成功"的ACK。
2.2 刷盘策略：SYNC_FLUSH 与 ASYNC_FLUSH 的分水岭
RocketMQ用 FlushDiskType 参数控制刷盘方式，这是决定消息丢失与否最关键的一把钥匙：
| 参数值 | 写入流程 | 可靠性 | 性能损耗 | 默认情况 |
|---|---|---|---|---|
| ASYNC_FLUSH | 消息写入PageCache即返回成功，后台异步刷盘 | 低，宕机会丢数据 | 小，吞吐量高 | 默认值 |
| SYNC_FLUSH | 消息写入PageCache后，必须等force落盘成功才返回ACK | 高，落盘成功即不丢 | 大，吞吐量明显下降 | 否 |
多数生产环境默认用ASYNC_FLUSH，因为性能好。你算一笔账就知道差距：异步刷盘下，单Broker写TPS能到几万甚至十万级别；同步刷盘时，每次写入都要等待磁盘IO完成，TPS可能直接折半。
**这里有个非常容易踩的坑：很多人以为把FlushDiskType改成SYNC_FLUSH就万事大吉了，却忽略了另一个参数 FlushDiskType 只在单机层面保证落盘。主从架构下，Master即使落盘了，如果Slave还没来得及同步，Mast