RocketMQ通过同步刷盘和同步复制实现最高级别消息可靠性：同步刷盘要求消息写入磁盘后才返回成功，同步复制要求主从节点均写入内存才返回ACK，二者组合可实现“零丢失”，但会降低性能。
主从同步：消息写入时的可靠性保障
RocketMQ 主从同步解决的是消息在多节点间复制的问题，核心目标是防止单点故障导致数据丢失。它和刷盘机制属于不同层面的设计——主从同步关注“跨节点”，刷盘关注“内存到磁盘”。
主从同步有两种模式：
- 异步复制（Async Replication）：Producer 发送消息到 Master 后，Master 写入本地 CommitLog 并立即返回成功，同时异步将数据同步给 Slave。性能高，但若 Master 突然宕机且未完成同步，可能丢失少量消息。
- 同步双写（Sync Replication）：Master 必须等 Slave 将消息写入自身内存（非必须刷盘），并返回 ACK 后，才向 Producer 返回成功。这能显著提升数据安全性，尤其适合金融、订单等强一致性场景，但会增加写入延迟。
注意：同步双写只保证消息进入 Slave 内存，并不强制 Slave 刷盘；是否刷盘由 Slave 自身的 flushDiskType 参数决定。
刷盘机制：消息落盘的关键控制点
刷盘是 Broker 将内存中待持久化的消息真正写入磁盘的过程，直接影响宕机后能否恢复数据。RocketMQ 提供两种策略：
- 异步刷盘（ASYNC_FLUSH）：消息追加到 CommitLog 的内存映射文件（MappedByteBuffer）后即返回成功，后台有单独线程定时或按量刷盘。吞吐高，但 Broker 异常崩溃时，未刷盘的消息会丢失。适用于验证码、通知类等允许少量丢失的业务。
- 同步刷盘（SYNC_FLUSH）：Producer 线程会阻塞，直到消息被真正写入磁盘（fsync），收到 OS 级确认后才返回。可靠性极高，但性能下降约 20%–30%，适合交易流水、资金变更等不可容忍丢失的场景。
实际配置通过 Broker 配置项 flushDiskType=SYNC_FLUSH 或 ASYNC_FLUSH 控制，建议搭配 flushInterval（异步刷盘间隔，默认10秒）和 flushCommitLogLeastPages（触发刷盘的最小页数）做精细调优。
主从 + 刷盘组合：可靠性与性能的权衡选择
单独开启同步双写或同步刷盘都不能完全避免消息丢失，二者需协同设计：
- 若仅用 异步复制 + 异步刷盘：Broker 宕机+断电可能导致主从都丢失未刷盘消息，可靠性最低。
- 若采用 同步双写 + 同步刷盘：Master 和 Slave 均完成磁盘写入才返回，可做到“零丢失”，但延迟明显上升，集群整体吞吐受限。
- 更常见的生产实践是：同步双写 + Slave 异步刷盘。Master 同步刷盘确保本地不丢，Slave 在内存中接收到副本已满足多数故障切换需求；即使 Slave 宕机，也可快速从 Master 拉取补全，兼顾安全与效率。
此外，RocketMQ 的 transientStorePool 机制可进一步优化同步刷盘性能——它预分配堆外内存池，避免频繁 GC 和内存拷贝，让 fsync 更快更稳。
存储结构支撑：为什么能兼顾高性能与高可靠
RocketMQ 的底层存储设计是上述机制得以落地的基础：
- CommitLog 顺序写：所有 Topic 消息统一追加到单个大文件，避免随机 IO，极大提升磁盘吞吐。
- ConsumeQueue 分区索引：为每个 Queue 维护独立的逻辑索引文件，支持快速定位消息，不影响 CommitLog 的写入效率。
- MappedByteBuffer 零拷贝：利用 JVM 内存映射技术，减少用户态/内核态数据拷贝，加速读写路径。
- 文件分段 + 过期清理：CommitLog 按固定大小（默认1G）分片，过期文件由后台线程定时删除，避免无限增长。
这些设计共同支撑了刷盘与主从同步的高效执行，让 RocketMQ 在万级 TPS 下仍保持亚毫秒级延迟。
