服务器非正常断电是数据安全的终极考验。本文从操作系统底层原理出发，深入剖析数据从内存到硬盘的“刷盘”过程，并结合RocketMQ、Kafka等消息队列的具体设计，揭示了在极致性能与数据安全之间取得平衡的关键策略。
智能速览
非正常断电导致数据丢失，根源在于操作系统为提速而设计的PageCache内存缓冲机制。
`fsync()`系统调用是强制将内存数据写入物理硬盘、确保数据安全的关键指令。
RocketMQ通过“组提交”策略，批量执行刷盘，兼顾了高吞吐量与数据强一致性。
RabbitMQ的持久化队列默认不保证每条消息即时刷盘，需借助发布确认机制增强安全。
Kafka默认配置优先性能，将刷盘任务交由操作系统，通过副本机制保障数据高可用。
精华内容
从理论到实战，深入探索Write与Fsync的奥秘，看三大消息队列如何巧用刷盘策略。
刷盘的底层原理
当应用程序调用`write()`方法写入数据时，操作系统为了提升性能，通常不会立即写入物理硬盘，而是将数据暂存于内核空间的PageCache中，然后立即返回成功。若此时发生非正常断电，PageCache中的数据将彻底丢失。
要确保数据真正持久化，必须调用`fsync()`指令，该指令会强制操作系统将PageCache中的所有“脏数据”同步写入磁盘，并在操作完成后才返回。通过Java代码与Linux的`strace`工具对比可以发现，使用`FileChannel`并调用`force()`方法会触发`fsync()`系统调用，而普通的`FileOutputStream`的`flush()`方法则不会，这正是两者在数据安全上的根本区别。
RocketMQ的组提交
RocketMQ在同步刷盘模式下，为保证数据不丢且性能不受影响，设计了一套精妙的“组提交”策略。它引入了两个队列：写队列和读队列，所有刷盘请求先进入写队列。
后台有一个专门的`GroupCommitService`线程，默认每10毫秒将写队列的请求转移到读队列，并对读队列中积攒的一批请求只执行一次`fsync()`操作。这种设计用一次物理IO的成本完成了一批消息的持久化，既保证了数据的绝对安全，又将性能损耗降到最低，是其能够支撑高TPS的关键之一。
RabbitMQ与Kafka策略
RabbitMQ在经典队列模式下，即使将队列声明为持久化，也并非为每条消息都执行刷盘操作。其官方文档明确指出，这中间存在一个时间间隔，缓存中的数据可能因断电而丢失。若需更强的保障，需启用“发布确认”机制，通过生产者与Broker的确认交互来确保消息已安全接收。
Kafka则更为激进，其在性能上的追求极致。在默认配置下，`log.flush.interval.messages`和`log.flush.interval.ms`的参数设置基本等于放弃了主动`fsync`，完全依赖操作系统的调度。Kafka的数据安全更多是依靠其集群的多副本（Replica）与ACK确认机制来共同保障的，在单机刷盘层面，它选择了优先保证性能。
理解刷盘机制是保障数据安全的基础。不同系统在性能与安全间的取舍各不相同，没有最优解，只有最适解。你的系统又该如何选择？
