面向云数据库，超低延迟文件系统PolarFS诞生了

高可用架构来提供PolarCtrl服务的持续性，当PolarCtrl因崩溃恢复出现的短暂故障间隙，由于PolarSwitch的缓存以及ChunkServer数据平面的局部元数据管理和自主leader选举的缘故，PolarFS能够尽量保证绝大部分数据I／O仍能正常服务。I/O 流程下面我们通过一个I/O的处理来说明各组件的互动过程。PolarFS执行写I/O请求的过程如上图所示：数据副本一致性模型ParallelRaft协议设计动机一个产品级别的分布式存储系统需要确保所有提交的修改在各种边界情况下均不丢失。PolarFS在Chunk层面引入一致性协议来保证文件系统数据的可靠性和一致性。设计之初，从工程实现的成熟度考虑，我们选择了Raft算法，但对于我们构建的超低延迟的高并发存储系统而言，很快就遇到了一些坑。Raft为了简单性和协议的可理解性，采用了高度串行化的设计。日志在leader和follower上都不允许有空洞，其意味着所有log项会按照顺序被follower确认、被leader提交并apply到所有副本上。因此当有大量并发写请求执行时，会按顺序依次提交。处于队列尾部的请求，必需等待所有之前的请求已被持久化到硬盘并返回后才会被提交和返回，这增加了平均延迟也降低了吞吐量。我们发现当并发I／O深度从8升到32时，I／O吞吐量会降低一半。Raft并不十分适用于多连接的在高并发环境。实际中leader和follower使用多条连接来传送日志很常见。当一个链接阻塞或者变慢，log项到达follower的顺序就会变乱，也即是说，一些次序靠后的log项会比次序靠前的log项先到。但是，Raft的follower必需按次序接收log项，这就意味着这些log项即使被记录到硬盘也只能等到前面所有缺失的log项到达后才能返回。并且假如大多数follower都因一些缺失的项被阻塞时，leader也会出现卡顿。我们希望有一个更好的协议可以适应这样的情形。由于PolarFS之上运行的是Database事务处理系统，它们在数据库逻辑层面的并行控制算法使得事务可以交错或乱序执行的同时还能生成可串行化的结果。这些应用天然就需要容忍标准存储语义可能出现的I／O乱序完成情况，并由应用自身进一步保证数据一致性。因此我们可以利用这一特点，在PolarFS中依照存储语义放开Raft一致性协议的某些约束，从而获得一种更适合高I／O并发能力发挥的一致性协议。我们在Raft的基础上，提供了一种改进型的一致性协议ParallelRaft。ParallelRaft的结构与Raft一致，只是放开了其严格有序化的约束。乱序日志复制Raft通过两个方面保障串行化：因此，ParallelRaft与Raft最根本的不同在于，当某个entry提交成功时，并不意味着之前的所有entry都已成功提交。因此我们需要保证：有了这两点，结合数据库或其他应用普遍存在的对存储I／O乱序完成的默认容忍能力，就可以保证它们在PolarFS上的正常运转，并获得PolarFS提供的数据可靠性。ParallelRaft的乱序执行遵循如下原则：容易知道，依照此原则完成的I／O不会违反传统存储语义的正确性。接下来我们来看log的ack-commit-apply环节是如何因此得到优化并且保持一致性的。ParallelRaft引入了一种新型的数据结构look behind buffer来解决apply中的问题。通过上述的异步ack、异步commit和异步apply，PolarFS的chunk log entry的写入和提交避免了次序造成的额外等待时间，从而有效缩减了高并发3副本写的平均时延。ParallelRaft协议正确性我们在ParallelRaft的设计中，确保了Raft协议关键特性不丢失，从而保障了新协议的正确性。PolarFS中与POLARDB紧密相关的设计文件系统多副本高速写入——数据库单实例的超高TPS，数据高可靠PolarFS设计中采用了如下技术以充分发挥I/O性能：在相同硬件环境下的对比测试，PolarFS中数据块3副本写入性能接近于单副本本地SSD的延迟性能。从而在保障数据可靠性的同时，极大地提升POLARDB的单实例TPS性能。下图是我们采用Sysbench对不同负载进行的初步测试比较。用例负载：OLTP，只读、只写（update : delete : insert = 2:1:1）、读写混合（read : write = 7:2）。数据库测试集数据量为500GB。可以发现POLARDB在PolarFS下取得了较好的性能，PolarFS同时支持了POLARDB的高TPS和数据的高可靠性。文件系统共享访问——写多读的数据库QPS强扩展，数据库实例的FailoverPolarFS是共享访问的分布式文件系统，每个文件系统实例都有相应的Journal文件和与之对应的Paxos文件。Journal文件记录了metadata的修改历史，是共享实例之间元数据同步的中心。Journal文件逻辑上是一个固定大小的循环buffer。PolarFS会根据水位来回收journal。Paxos文件基于Disk Paxos实现了分布式互斥锁。由于journal对于PolarFS非常关键，它们的修改必需被Paxos互斥锁保护。如果一个节点希望在journal中追加项，其必需使用DiskPaxos算法来获取Paxos文件中的锁。通常，锁的使用者会在记录持久化后马上释放锁。但是一些故障情况下使用者不释放锁。为此在Paxos互斥锁上分配有一个租约lease。其他竞争者可以重启竞争过程。当PolarFS当节点开始同步其他节点修改的元数据时，它从上次扫描的位置扫描到journal末尾，将新entry更新到memory cache中。下图展示了文件系统元数据更新和同步的过程。PolarFS的上述共享机制非常适合POLARDB一写多读的典型应用扩展模式。一写多读模式下没有锁争用开销，只读实例可以通过原子I/O无锁获取Journal信息，从而使得POLARDB可以提供近线性的QPS性能扩展。由于PolarFS支持了基本的多写一致性保障，当可写实例出现故障时，POLARDB能够方便地将只读实例升级为可写实例，而不必担心底层存储产生不一致问题，因而方便地提供了数据库实例Failover的功能。文件系统级快照——POLARDB的瞬时逻辑备份对于百TB级超大数据库实例的备份而言，数据库快照是必须支持的功能。PolarFS采用了自有的专利快照技术，能够基于位于底层的多个ChunkServer的局部快照，构建Volume上的统一的文件系统即时映像。POLARDB利用自身数据库的日志，能够基于此文件系统映像快速构建出此具体时点的数据库快照，从而有效支持数据库备份和数据分析的需求。可以发现，POLARDB的高性能、强扩展、轻运维等具备竞争优势的优异特性，与PolarFS的紧密协作息息相关，PolarFS发挥了强大的使能作用。结论PolarFS是一个专为云数据库而设计的分布式文件系统，其能够支持跨节点高可靠性同时提供极