Raft 算法在分布式存储系统 Curve 中的实践

做为网易数帆开源的高性能、高可用、高可靠的新一代分布式存储系统，Curve对于多副本数据同步、负载均衡、容灾恢复方面都有较高的要求。网易数帆存储团队选用Raft算法做为Curve底层一致性协议，并基于Raft的特性，实现了异常状况下的数据迁移和自动恢复。本文首先简要介绍一下Raft算法的一些基本概念和术语，再详细介绍其在Curve中的实践。

Raft一致性算法介绍

Raft算法中，有Leader、Follower、Candidate三种角色，它们之间的转换关系以下图：

在同一时刻，只能有一个Leader，当选Leader后到发起下一次选举称为一个任期（term），Leader负责经过心跳向follower保持统治，并同步数据给Follower。Follower发起选举的前提是超时未收到Leader的心跳。

Leader竞选：RAFT是一种Majority的协议，即赢得选举的条件是得到包括本身之内的大多数节点的投票。Follower超时未收到Leader的心跳，则会成为Candidate，发起新一轮的选举。每一个节点在每一个Term内只能投一次票，且服从先到先服务原则。为了不多个Follower同时超时，raft中的选举超时时间是一个固定时间加一个随机时间。

日志复制：在任期内，Leader接收来自client的请求，并将其封装成一个日志条目（Raft Log Entry）把它append到本身的raft log中，而后并行地向其它服务器发起AppendEntries RPC，当肯定该entry被大多数节点成功复制后（这个过程叫commit），就能够执行命令（这一步叫apply），并返回给client结果。log entry由三个部分组成，分别是：一、log index，二、log所属的term，三、要执行的命令。

配置变动：在Raft中，称复制组有哪些成员称为配置，配置并非固定的，会根据需求增删节点或异常状况下须要替换掉有问题的节点。从一个配置直接切换到另外一个配置是不安全的，由于不一样的服务器会在不一样的时间点进行切换。所以Raft配置变动时，会先建立一个特殊的log entry Cold,new，这条entry被commit后，会进入共同一致阶段，即新旧配置一块儿作决定。这时候，再生成一个Cnew的log entry，等这条entry被commit后，就能够由新配置独立作决定了。

安装快照：Raft快照指的是某个时刻保存下来的系统状态的集合。快照有两方面的做用：一个是日志压缩，打了快照以后，在此时刻以前的log entry就能够删除了。另外一个是启动加速，系统起来的时候不须要从新回放全部日志。当Leader同步日志给Follower的时候，发现所需的log entry已经被快照删掉了，便可经过发送InstallSnapshot RPC给Follower进行同步。

Raft算法在Curve中的应用

Curve系统是一个分布式存储系统，在Curve系统中，数据分片的最小单位称之为Chunk，默认的Chunk大小是16MB。在大规模的存储容量下，会产生大量的Chunk，如此众多的Chunk，会对元数据的存储、管理产生必定压力。所以引入CopySet的概念。CopySet能够理解为一组ChunkServer的集合，一个Copyset管理多个Chunk，多副本间的同步和管理已Copyset为单位组织。ChunkServer，Copyset和Chunk三者之间的关系以下图：

Curve copyset选用了braft做为一致性协议的组件，使用方式为multi-raft，即同一个机器，能够属于多个复制组，反过来讲，一个机器上，能够存在多个raft实例。基于braft，咱们实现了副本间数据同步，系统调度，轻量级raft快照等功能，下面一一详细介绍。

副本间数据同步

CopysetNode在ChunkServer端封装了braft node，具体关系以下图所示：

Curve client发送一个写请求时，三副本状况下的具体的步骤以下：

1. Client发送写请求给Leader ChunkServer。

2. ChunkServer收到请求，将请求封装成一个log entry，提交给raft。

3. braft模块在本地持久化entry的同时发送entry给其余副本（ChunkServer）。

4. 本地持久化entry成功，且另外一个副本也落盘成功则commit。

5. commit后执行apply，apply即执行咱们的写盘操做。

在此过程当中，用户的数据和操做，经过braft中的log entry的方式在副本间传递，进行数据同步。在三副本场景下，向上层返回的时间取决于两个较快的副本的速度，所以能够减小慢盘的影响。对于较慢的那个副本，leader也会经过无限重试的方式同步数据，所以在系统正常工做的前提下，最终三个副本的数据是一致的。

基于Raft的系统调度

在Curve中，ChunkServer按期向元数据节点MDS上报心跳，心跳中除了ChunkServer自身的一些统计信息，还包含ChunkServer上面的CopySet的统计信息，包含它的leader，复制组成员，是否有配置变动执行中，配置的epoch等。MDS基于这些统计信息，会生成一系列的Raft配置变动请求并下发给Copyset的leader所在的ChunkServer。

下发配置变动

Curve ChunkServer会按期向MDS上报心跳。MDS调度下发配置变动是在心跳的response中完成的。上报心跳的过程以下图：

心跳是定时任务触发的，ChunkServer除了上报一些本身的容量信息等统计信息外，还会上报Copyset的一些信息，好比leader，成员，epoch，是否有进行中的配置变动等。

MDS在心跳response中下发配置变动的过程以下图：

ChunkServer收到response后，解析其中的配置变动信息，并下发给每一个Copyset。

Curve epoch

epoch同步配置。MDS生成的调度信息，是由后台定时任务触发，并在ChunkServer下一次请求到来时在response中下发的，所以MDS下发的配置变动有多是过时的。为了实现MDS和ChunkServer之间的配置同步，Curve引入了epoch机制，初始状态，epoch初始为0，每进行一次配置变动（包括leader变动），epoch都会加一。当MDS中的epoch等于ChunkServer端的epoch时，即将下发的配置变动才被认为是有效的。epoch与term有何区别？term用于表示Leader的任期，即只跟选举有关，而epoch是与配置变动相关的，也包括了Leader选举这种状况。

epoch的更新。epoch是在ChunkServer端更新的，braft在实现上提供了一个用户状态机，在braft内部发生变化，好比apply，出错，关闭，打快照，加载快照，leader变动，配置变动等时会调用用户状态机中对应的函数。Curve copyset经过继承的方式实现这个用户状态机来完成与braft的交互，epoch是在on_configuration_committed函数中加一的。在braft中，当Leader变动的时候会把当前的配置再提交一遍，所以在on_configuration_committed中增长epoch便可保证在配置发生变化或者Leader变动时epoch顺序递增。

epoch的持久化。在MDS端，epoch随着CopySet的其余信息一块儿持久化在etcd中。ChunkServer也对epoch进行了持久化，可是ChunkServer中持久化epoch并非每次epoch发生变化都须要持久化的。这是利用了raft的日志回放和快照功能。考虑如下两种状况：

1. 假设raft没有打快照，那么就不须要持久化epoch，由于全部操做日志，包括配置变动的entry都已持久化，当服务重启的时候，回放这些日志的时候会依次再调用一遍on_configuration_committed，最后epoch会恢复到重启前的值。

2. 当raft有快照时，打快照前的entry都会被删除，就不能经过上面的方式回放，所以必需要持久化。但咱们只须要在打raft快照时持久化epoch的当前值便可。这样当系统重启的时候，会先安装raft快照，安装后epoch恢复到快照时的值，再经过执行后面的log entry，最终epoch恢复到重启前的值。在打快照时更新epoch是在on_snapshot_save函数中完成的。

Raft轻量级快照

上面介绍Raft算法的时候介绍过，Raft须要定时打快照，以清理老的log entry，不然Raft日志会无限增加下去。打快照的时候须要保存系统当前的状态，对于Curve块存储场景来讲，系统状态就是Chunk当前的数据。直观的方案是将打快照时刻的所有chunk拷贝一遍备份起来。可是这样有两个问题：

1. 空间上要多出一倍，空间浪费很是严重。

2. Curve默认打快照的间隔是30分钟一次，这种方案下会有频繁的数据拷贝，对磁盘形成很大的压力，影响正常的IO。

所以，Curve中使用的Raft快照是轻量级的，即打快照的时候只保存当前的Chunk文件的列表，不对Chunk自己作备份。具体流程以下：

这样操做，Follower下载到的chunk文件不是打快照时的状态，而是最新的状态，在回放日志的时候，会把这些新数据再写一遍。但这对于咱们的场景是能够接受的，由于底层都是覆盖写是幂等的，即写一次和写屡次结果是一致的。

小结

本篇文章首先介绍了Raft一致性算法的一些基本概念。随后介绍了Raft算法新一代高性能分布式存储系统Curve中的应用，分别从数据同步、系统调度和Raft快照三个角度介绍了Curve中使用Raft的细节。关于Curve的更多介绍详见咱们的代码仓库：https://github.com/opencurve/curve。另外，Curve开源分享也在火热进行中，分享的PPT能够在https://github.com/opencurve/curve-meetup-slides仓库中获取。

做者简介

查日苏，网易数帆存储团队高级C++开发工程师，高性能分布式存储系统Curve核心开发。

---

相关视频：

Curve核心组件之ChunkServer数据节点

相关文章：

Curve技术解析之MDS元数据管理

分布式存储开发：Curve中的内存管理

网易数帆存储负责人亲述：我眼中的Curve与Ceph

Curve的roadmap

分享预告：

Curve系列技术课程，每周五晚19:00 B站直播，本周五主题为 Curve 快照克隆，敬请点击收看：Curve开源技术直播（每周五19:00）