Mysql 宕机引发索引丢失很可怕，文件 IO 中如何保证掉电不丢失数据？

点击上方“服务端思维”，选择“设为星标”

回复”669“获取独家整理的精选资料集

回复”加群“加入全国服务端高端社群「后端圈」

好久没有分享文件 IO 的小技巧了，依稀记得上次分享还是在上次。

第二届云原生编程挑战赛正在火热进行中，Kirito 也在做《针对冷热读写场景的RocketMQ存储系统设计》这个题目，不过参与的是内部赛道，没法跟外部的小伙伴们一起排名了。

众所周知，存储设计离不开文件 IO，将数据存储到文件中进行持久化，是大多数消息队列、数据库系统的常规操作。在比赛中，为了更贴近实际的生产场景，往往也会引入正确性检测阶段，以避免让选手设计一些仅仅支持内存行为的代码逻辑。试想一下，RocketMQ 或者 Mysql 在宕机之后因为索引丢失，而导致数据无法查询，这该是多么可怕的一件事！

正确性检测要求我们写入的数据能够被查询出来，没有丢失，按照我个人的参赛经验，通常分为三种级别

• 进程正常退出或者进程被 kill -15 中断
• 进程被 kill -9 中断
• 系统掉电

第一个级别，进程正常退出或者进程被 kill -15 中断，该场景没有什么好讲的，一般评测程序会留出 destroy 、close 等回调接口，用于显式关闭，或者在 Java 中使用 JVM 提供的 ShutdownHook 监听 -15 信号，这是最简单的一种场景，一般不需要考虑数据一致性的问题。在实际生产中，对应我们优雅退出、手动关机的流程。

第二个级别，进程被 kill -9 中断。这意味着，我们使用内存去聚合一些数据可能是受限的，但我们仍然可以利用操作系统的一些特性，例如 PageCache 去做缓存。毕竟进程挂了，机器可没挂。在实际生产中，对应我们遇到一些内存溢出、FullGC 重启进程等暴力退出程序的场景。

第三个级别，系统掉电。这也是我这篇文章的主角，同时也是数据一致性要求最高的级别。系统掉电意味着我们甚至连 PageCache 都不能直接利用，必须严格保证数据落到磁盘当中。在实际生产中，对应主机宕机，机房断电等场景。

可以发现，任何一个级别，都有他们实际应用的场景，越是一致性要求高的级别，通常性能就越差，能够利用的手段也越少，系统也就越难设计。

而这次比赛的正确性描述

1. 写入若干条数据。
2. 重启机器
3. 再读出来，必须严格等于之前写入的数据

其中的重启机器环节，恰恰是模拟的掉电。

如何理解数据不丢失

在介绍 Java 文件 IO 中保证掉电不丢失的手段之前，我还需要做一个概念的介绍，这样方便我们更好的理解文章后续的观点。

很多同学可能有疑惑，如果一个数据写到一半，发生了掉电，那评测程序怎么知道这条数据落盘了没有呢？评测程序会不会读取这条数据呢？其实，对于”执行到一半“这种逻辑，谁都没有办法保证，正如系统真正掉电时，他可不会跟你商量。所以，在一般的评测中，去验证选手的数据一致性时，通常采取的做法是：当一个方法同步返回时，就应该认为这个数据落盘了，即使返回后立刻断电，也应该可以在重启之后，查询到这条数据。

这符合我们在实际开发/生产场景的认知：

• 对于同步方法，其实隐含了 ack 的契约，即拿到返回值的那一瞬间，认为对方处理完毕了。
• 对于异步方法，我们才需要增加回调或者轮询 ack 的机制。

Java 文件 IO 保障掉电不丢数据

在《文件 IO 操作的一些最佳实践》一文中，我其实已经介绍了，Java 中无非就一个 FileChannel 是最常用的文件操作类。FileChannel 的 write 方法看似是一个同步方法，将内存数据写入了磁盘，但其实它和磁盘之间还隔着一层 PageCache。

尽管操作系统可能很快就将 PageCache 刷入到了磁盘，但这个过程仍然是一个异步的过程。就以这次比赛而言，如果你仅仅数据写入到 PageCache 就不管不问了，肯定是无法通过正确性检测的。

解决方法也很简单，调用 FileChannel#force(boolean meta) 方法即可，该方法会强制操作系统将 PageCache 刷盘。

force 的入参是一个 boolean 值，代表是否将元数据也刷盘，这块网上资料比较少，我也没有详细的依据。按照我个人的理解，元数据包含了大小和时间戳信息，可能会影响文件的实际长度，所以 force(true) 可能更稳妥一些。

结合第二节中介绍的内容，我们只需要保证在每次写入操作返回之前，调用 force，即可实现掉电数据不丢失的效果。

那么，代价是什么呢？意味着我们完全丧失了操作系统给文件 IO 设置的一道缓存。在没有缓存又没有 4kb 对齐的情况下，写入放大问题将会非常明显。

这里用一份数据说话，根据官方给出的数据，这次评测使用的 SSD 吞吐可达到 320MiB/s，而我实测在不经过优化的场景下使用 force，仅仅能达到 50 Mib/s，直接会导致评测超时。

force 是掉电的拯救者，也可能是性能的毁灭者。

force 下可能的优化方案

在实际场景中，消息的生产者可能会同步地连续地发送多条消息，也有可能会有多个生产者一起在发送消息，尽管消息的投递是同步的，但我们仍然可以在多个不同生产者的消息之间做一些文章，在保证 force 的同时，减少写入放大的问题。

鉴于比赛还在进行中，我就不过多聊详细设计了，懂的应该看到上面这段话都懂了，还算是比较基础的优化。我在优化过后，可以保证在 force 的前提下，将吞吐量从 50 Mib/s 提升到 275 Mib/s，尽管离理论值还是有所差距，但已经足够出一个 baseline 了。

RocketMQ 中的实际应用

以 RocketMQ 为例，聊聊其是如何保障数据不丢失的。RocketMQ 在 Broker 侧保障数据不丢失主要有两种机制：

1. RocketMQ 支持配置同步双写，保障消息在主节点之外，还在一个从节点有备份
2. RocketMQ 支持同步刷盘策略，即本文介绍的 FileChannel#force(boolean meta)  方案

今天对文件 IO 的理解有没有多一点点呢，如果你愿意多花点时间阅读这篇文章的话，你就会发现多花了点时间。对了，这次比赛，我有拉一个小群，欢迎对比赛感兴趣的同学加我微信 xiayimiaoshenghua 进群交流，或者留言讨论哦。