详细介绍了RocketMQ的消息刷盘策略，以及RocketMQ的消息双写机制。
文章目录 1 RocketMQ的消息刷盘2 RocketMQ的消息双写
1 RocketMQ的消息刷盘
同步刷盘：如上图所示，只有在消息真正持久化至磁盘后RocketMQ的Broker端才会真正返回给Producer端一个成功的ACK响应。同步刷盘对MQ消息可靠性来说是一种不错的保障，但是性能上会有较大影响，一般适用于金融业务应用该模式较多。
异步刷盘：能够充分利用OS的PageCache的优势，只要消息写入PageCache即可将成功的ACK返回给Producer端。消息刷盘采用后台异步线程提交的方式进行，降低了读写延迟，提高了MQ的性能和吞吐量。
一般异步刷盘只有在Broker意外宕机的时候会丢失部分数据，因为即使Broker服务崩溃，只要系统没有崩溃，最终系统内核也会自动将pageCache的数据刷盘，可以通过设置 Broker 配置文件的参数 FlushDiskType 来调整刷盘策略ASYNC_FLUSH 或者 SYNC_FLUSH。
2 RocketMQ的消息双写RocketMQ的消息双写主要是指的Borker主从模式下，主节点返回ack消息给客户端的时候是否需要等待消息从主节点同步到从节点。
消息需要从主节点同步（复制）到从节点上，有同步和异步两种复制方式。另外，RocketMQ 是不支持自动主从切换，当主节点挂掉之后，生产者就不能再给这个主节点生产消息了，需要人工干预，但是消费者还可以自动切换到从节点进行消费。
同步复制：也叫 同步双写，只有消息同步双写到主从结点上时才返回写入成功。如果Master出故障，Slave上有全部的备份数据，容易恢复，且消费者仍可以从Slave消费，消息不丢失。
异步复制：也叫异步双写，消息写入主节点之后就直接返回写入成功，此时系统拥有较低的延迟和较高的吞吐量，但如果Master出了故障，有些数据因为没有被复制到Slave，而丢失少量消息。
需要注意，异步双写的“消息丢失”和异步刷盘的“消息丢失”是不一样。采用异步复制的方式，在主节点挂掉的时间只会产生主从节点短暂的消息不一致的情况，降低了可用性，而当主节点重启之后，从节点那部分未来得及复制的消息还会继续复制过去，消息最终会被消费。
同步复制和异步复制可以通过Broker配置文件里的brokerRole参数进行设置，可以被设置成ASYNC_MASTER、SYNC_MASTER、SLAVE三个值中的一个。
相关文章：
RocketMQ
如有需要交流，或者文章有误，请直接留言。另外希望点赞、收藏、关注，我将不间断更新各种Java学习博客！