RocketMQ 刷盘策略详解

🚀 RocketMQ 刷盘策略详解：

同步刷盘 (SYNC_FLUSH) vs 异步刷盘 (ASYNC_FLUSH)

深入理解其对性能与数据可靠性的影响

在 RocketMQ 中，刷盘策略（Flush Strategy） 是影响数据可靠性和系统性能的核心配置之一。它决定了消息写入磁盘的时机与方式，直接关系到系统在宕机时是否丢失数据。

RocketMQ 提供了两种刷盘方式：

• 同步刷盘（SYNC_FLUSH）
• 异步刷盘（ASYNC_FLUSH）

本文将深入解析这两种策略的工作原理、性能对比、适用场景及最佳实践。

---

一、什么是“刷盘”？

✅ 定义：

“刷盘”是指将操作系统 PageCache 中的数据持久化写入磁盘的过程。

📌 背景：
RocketMQ 使用 mmap + PageCache 技术提升写入性能。消息先写入内存映射文件（PageCache），再由操作系统异步刷入磁盘。
如果不主动刷盘，机器宕机时可能导致数据丢失。

---

二、1. 同步刷盘（SYNC_FLUSH）

✅ 工作原理：

• 消息写入 CommitLog 的 PageCache 后，立即调用 fsync() 或 fdatasync() 将数据强制刷入磁盘
• 只有磁盘确认写入成功后，Broker 才向 Producer 返回 SEND_OK

Producer → 发送消息
   ↓
Broker 写入 PageCache
   ↓
调用 fsync() 等待磁盘完成写入
   ↓
返回 ACK 给 Producer

🔧 配置方式：

# 在 broker.conf 中设置
flushDiskType=SYNC_FLUSH

✅ 优点：

优势	说明
数据高可靠	即使 Broker 宕机，只要返回成功，消息就不会丢失
满足金融级要求	适用于对数据一致性要求极高的场景

❌ 缺点：

问题	说明
性能低	fsync() 是阻塞操作，频繁调用严重影响吞吐量
延迟高	每次写入都要等待磁盘响应（机械盘更明显）
吞吐下降明显	相比异步刷盘，TPS 可能下降 50%~90%

🎯 适用场景：

• 金融交易系统（如转账、扣款）
• 对账系统
• 任何不允许消息丢失的关键业务

---

三、2. 异步刷盘（ASYNC_FLUSH）

✅ 工作原理：

• 消息写入 PageCache 后，立即返回 ACK 给 Producer
• 由后台线程定时或定量触发刷盘（如每 500ms 调用一次 fsync）

Producer → 发送消息
   ↓
Broker 写入 PageCache
   ↓
立即返回 ACK
   ↓
后台线程定期将数据刷入磁盘

🔧 配置方式：

# 在 broker.conf 中设置
flushDiskType=ASYNC_FLUSH

✅ 优点：

优势	说明
高性能	写入不阻塞，吞吐量高（可达数万~数十万 TPS）
低延迟	Producer 几乎无等待
适合高并发场景	电商、日志、消息通知等

❌ 缺点：

问题	说明
可能丢消息	若 Broker 在刷盘前宕机，PageCache 中未刷盘的消息会丢失
依赖操作系统稳定性	数据可靠性部分依赖 OS 和硬件

🎯 适用场景：

• 订单创建、用户注册
• 日志采集、监控上报
• 允许极小概率丢失的非核心业务

---

四、SYNC_FLUSH vs ASYNC_FLUSH 对比表

特性	同步刷盘 (SYNC_FLUSH)	异步刷盘 (ASYNC_FLUSH)
数据可靠性	⭐⭐⭐⭐⭐ 极高（几乎不丢）	⭐⭐⭐ 一般（可能丢少量）
性能（TPS）	低（1k~5k）	高（10k~100k+）
延迟	高（几 ms ~ 几十 ms）	低（<1ms）
磁盘压力	高（频繁 fsync）	低（批量刷）
适用场景	金融、对账、强一致	电商、日志、通知
推荐使用	❌ 仅关键场景	✅ 大多数场景

---

五、如何选择刷盘策略？—— 决策建议

业务需求	推荐策略	理由
绝对不能丢消息	SYNC_FLUSH	数据安全第一
高吞吐、低延迟优先	ASYNC_FLUSH	性能优先
可容忍少量丢失	ASYNC_FLUSH	成本与风险平衡
混合场景	分 Topic 配置	关键 Topic 用 SYNC，其他用 ASYNC

⚠️ 注意：RocketMQ 不支持 per-topic 刷盘策略，整个 Broker 统一配置。

---

六、增强可靠性的组合策略（推荐）

即使使用 ASYNC_FLUSH，也可以通过以下方式提升数据可靠性：

1. 主从复制（Master-Slave）

• Master 写入 PageCache 后，同步复制给 Slave
• 即使 Master 宕机，Slave 仍可能保留数据
• 配合 SYNC_MASTER 或 ASYNC_MASTER 使用

brokerRole=ASYNC_MASTER  # 推荐

2. Dledger 模式（推荐用于高可用）

• 基于 Raft 协议实现多副本强一致性
• 自动选主，支持自动故障转移
• 即使使用 ASYNC_FLUSH，也能保证多数节点持久化

适用于金融、支付等强一致性场景。

---

七、性能测试参考（典型值）

配置	TPS（条/秒）	平均延迟
ASYNC_FLUSH + SSD	80,000+	<1ms
ASYNC_FLUSH + HDD	30,000~50,000	1~3ms
SYNC_FLUSH + SSD	5,000~10,000	5~20ms
SYNC_FLUSH + HDD	1,000~3,000	20~100ms

💡 提示：SSD 能显著提升 SYNC_FLUSH 性能。

---

八、最佳实践建议

实践	说明
✅ 生产环境默认使用 ASYNC_FLUSH	性能与可靠性平衡
✅ 关键业务启用主从复制	避免单点故障
✅ 使用 SSD 磁盘	提升刷盘性能，尤其对 SYNC_FLUSH
✅ 监控磁盘 IO 和刷盘延迟	及时发现瓶颈
✅ 结合 flushDiskType 和 brokerRole 综合配置	实现高可用
❌ 避免在 HDD 上使用 SYNC_FLUSH	性能极差

---

✅ 总结

刷盘策略	核心思想	一句话总结
SYNC_FLUSH	安全第一，写完必须落盘	“宁可慢，也不能丢”
ASYNC_FLUSH	性能优先，批量刷盘	“先收下，回头再存”

🚀 最终建议：
绝大多数场景使用 ASYNC_FLUSH + 主从复制 即可满足可靠性要求。
只有在金融级强一致性场景下，才考虑使用 SYNC_FLUSH 或 Dledger 模式。

理解刷盘策略的本质，是在性能与数据安全之间做出合理权衡。掌握这一点，你就能为不同业务选择最合适的配置方案。