高效事务难点的三种解决方案+方法

方案一：Hook 到文件系统内部的事务机制 方案 1 的问题是功能有限，而且很多文件系统没有直接对用户暴露事务。功能有限例如没有回滚机制等。Btrfs 提供了一对系统调用使得内部的事务机制可以对用户暴露。基于 Btrfs 的 FileStore 第一版是依赖于这些系统调用的，但是它没有回滚机制导致很痛苦——具体来说，如果 Ceph OSD 在事务过程中遇到了一个 fatal 事件，例如软件崩溃或者 kill 信号，Btrfs 会提交一个部分（partial）事务，留给存储后端一个不一致状态。

Ceph 团队和 Btrfs 团队都接受的解决方法包括提供一个 entire transaction 系统调用，或者基于快照实现回滚，但这两个方案都有很高的成本。最近 Btrfs 废弃掉了事务系统调用，和微软对 NTFS 的决定类似。

方案二：在用户态实现 WAL 方案二是可行的，但是受三个主要问题的影响：

读取-修改-写入速度

一个用户态 WAL 实现每个事务需要三步：第一步、先对事务序列化，写入到日志；第二步、通过 fsync 持久化日志；第三步、执行事务内的操作

这样最终导致整个 WAL 的延迟很高，无法实现高效的 pipeline

非幂等操作

FileStore 中对象通过文件表示，对象集合会映射到目录。

在这种数据模型下，crash 之后重放 WAL 因为一些操作非幂等会导致很有难度。在 WAL 定时 trim 时，总会有一个时间窗口事务日志已经提交到文件系统但事务还没有完成（a window of time when a committed transaction that is still in the WAL has already been applied to the file system）。举个例子，考虑一个事务包含三个操作：①克隆a到b②更新a③更新c如果在第二步之后发生 crash 了，replay WAL 会破坏 b在考虑另一个例子，事务有四个操作：①更新b②将b重命名为c③将a重命名为b④更新d如果在第三个操作之后发生了 crash，重放 WAL 会破坏 a（也就是现在的 b），然后因为 a 已经不存在而失败。

基于 Btrfs 的 FileStore 通过对文件系统做周期性快照和对 WAL 做快找时间的标记来解决这一问题。当恢复时，最近的一个快照被恢复，然后 WAL 从相应时间点那一刻开始 replay。

但因为现在已经使用 XFS 来替代 Btrfs，XFS 缺乏快照带来了两个问题。首先，XFS 上 sync 系统调用是将文件系统状态落盘的唯一选择，但对一个典型的多磁盘构成的节点来说，sync 过于昂贵因为会对所有磁盘生效。这个问题已经被增加 syncfs 调用解决——只同步指定的文件系统。

第二个问题是在 WAL replay 后，恢复文件系统到指定状态会因为上面说的缺乏幂等性而产生问题。为此 Ceph 又引入了 Guards（序列号 sequence numbers ）来避免 replay 非幂等操作。但庞大的问题空间导致在复杂操作下 guards 的正确性也很难验证。Ceph 通过工具产生复杂操作的随机排列，然后加上错误注入来半自动的验证正确性，但最终结果是 FileStore 的代码很脆弱而且难以维护。

双写。最后一个问题是数据会被写两次，一份到 WAL 一份到文件系统，减半了磁盘的带宽。核心原因是大部分文件系统都只对元数据修改记录到日志，允许在 crash 后丢失数据。然而 FileStore 对文件系统的使用（namespace、state）因为一些 corner case（例如对多文件部分写 partially written files）导致 FileStore 不能像文件系统一样只在日志中记录元数据修改。

尽管可以说 FileStore 这种对文件系统的使用是有问题的，但这种选择也有技术原因的。如果不这么做就需要实现数据和元数据的内存 cache 以等待 WAL 的任何更新——而内核已经有了 page 和 inode 的缓存。

方案三：使用有事务的 KV 数据库 在 NewStore 方案中，元数据保存在 RocksDB，一个有序 KV 数据库，而对象数据继续在文件系统上以文件形式表示。这样，元数据操作直接在数据库执行；数据的覆盖写被记录到 RocksDB 然后延迟执行。下面介绍 NewStore 如何解决前面说到的用户态 WAL 的三个问题，然后介绍后面因为在一个日志文件系统上运行带来的极高的一致性成本。

首先，因为 KV 数据库的接口允许我们直接读取对象状态而不需要等待上一个事务完成，从而避免了缓慢的“读取-修改-写入”。

其次 replay 非幂等操作的问题通过在准备事务时在读取侧解决。举个例子，克隆 a 到 b，如果对象比较小，那么就复制一份并插入到事务，如果对象比较大，那么就用 COW 机制，将 a 和 b 指向到同一数据，并把数据标记为只读。

最后，双写的问题也解决了，因为对象的命名空间已经和目录结构解耦，新对象的数据都会先写到文件系统然后自动添加引用到数据库。

尽管上面说了许多好处，但与 journal on journal 类似，日志文件系统与 RocksDB 的组合会带来很高的一致性开销。在 NewStore 上创建对象需要两步：

写入一个文件并执行 fsync

同步将对象元数据写入到 RocksDB，也会导致一次 fsync

理想状态下，每次 fsync会导致一次昂贵的 FLUSH CACHE 操作到磁盘。但实际上在日志文件系统上每次 fsync会带来两次 flush command：一次是写数据，一次是文件系统提交元数据日志。这样导致在 NewStore 上创建对象会产生四次昂贵的 flush操作。

下面用一个模拟测试来展示这一开销，测试方法是模拟存储后端创建大量对象，每轮会先写 0.5MB 数据然后插入 500Byte 的元数据到 RocksDB。先模拟 NewStore （在 XFS 上）的实现，然后模拟在裸盘上的实现。