分布式存储：基于硬盘的RAFT状态机实现方法与挑战

正文

请到「今天看啥」查看全文

那么会出现一个问题：一个落后的 Follower 只包含了 80 条日志，不能通过同步 Leader 的日志来恢复。这时需要复制 Leader 通过 take snapshot 形成的状态机快照，这个快照包含了 80 条日志应用后的数据。完成快照同步后，再同步日志，最后 Follower 追上了 Leader，数据达成一致。然而实际上，状态机的数据规模远远大于 80 条日志，可能达到 TB 级别，这对落后 Follower 的数据同步来说是一个重大挑战。

在论文中大致提及到两种方法：一种是基于原地写（write in place）的方法，另外一种是基于追加写（append only）的方法。这两种方法理论上都可以传递完整一致的状态机镜像到落后的 Follower，但也面临着实际的问题。

原地写的方法

原地写的方法的主要问题是：在 RAFT 打快照时，需要同时给状态机打快照，以便可以方便地将某条日志之前的状态机镜像拷贝到落后的 Follower 上。但是在拷贝状态机快照镜像的过程中，可能会有新的用户 I/O 请求需要处理，这样在状态机镜像之外，可能会逐渐积累许多新增数据。论文中认为，这些新增的数据量不会太大，稍后通过同步 RAFT 日志即可。

但是在实际的分布式存储系统中，为了保证可用性，一方面会限制后台数据的流量，这样同步状态机镜像的时间肯定会被拉长。另一方面，在高速 NVME SSD 的加持下，前台用户 I/O 的写入性能可以达到单盘 2GB/s，甚至更高。那么 5~10 分钟就可以写入 1TB 数据，这么短的时间内，Follower 可能还未完成状态机镜像的同步，这时又会积累大量新增数据。这样一来，一方面硬盘空间浪费不小，另一方面 Follower 也很难追上 Leader 的进度，使得集群的可用性无法保证。

zStorage 分布式存储系统 ，同样基于 RAFT 实现，也采用了硬盘状态机原地写的实现方法：即数据先写到 RAFT 日志，再应用到硬盘状态机。不过当需要通过打快照删除过时的无效日志时，为了避免上述问题， zStorage 并未将状态机整体打一个快照，而是采用了一种新的方法，缓解了空间浪费和集群可用性问题。

在 zStorage 的硬盘状态机实现中，状态机由有限个 4MB 的 chunk 组成。这些 chunk 可以按照一个固定的顺序遍历，也可以认为 chunk 是有序的。简单理解为：chunk0, chunk1, chunk2, chunk3, ….. chunkn。然后在复制状态机到落后的 Follower 时，采用了一种方法：按照 chunk 的先后顺序，先复制一些 chunk 到 Follower，再复制一些日志到 Follower，如此交替进行。在复制过程中，维护一个分界线（chunk id），该分界线之前的部分是已经复制完成的，分界线之后的是未复制完成的。

请到「今天看啥」查看全文