深入解析 Raft 模块在 ZNBase 中的优化改造
2021-06-06 10:24:31 
阿炯
作者：管延信
第一部分
导读
云溪数据库 ZNBase 是由浪潮开源的一款 NewSQL 分布式数据库，具备 HTAP 特性，拥有强一致、高可用的分布式架构。对于一个高可用的分布式系统来说，为了保障不同集群不同节点的数据一致，一致性算法尤为重要。Raft 是一种管理日志复制的分布式一致性算法，包括 ZNBase 在内的很多分布式系统都采用 Raft 作为底层的一致性协议。本系列文章将为大家介绍 Raft 一致性算法在 ZNBase 中的落地实践，并深入解析 ZNBase 技术团队根据自身业务需求对 Raft 协议做出的五大优化改进。
Raft 简介
Raft 作为一种管理日志复制的分布式一致性算法，由斯坦福大学的 Diego Ongaro 和 John Ousterhout 在论文中提出。在 Raft 出现之前，Paxos 一直是分布式一致性算法的标准。但 Paxos 相对难以理解，Raft 的设计目标就是简化 Paxos，使得一致性算法更容易理解和实现。
Paxos 和 Raft 都是分布式一致性算法，其过程如同投票选举领袖(Leader)，参选者(Candidate)需要说服大多数投票者(Follower)给他投票，一旦选举出领袖，就由领袖发号施令。Paxos 和 Raft 的区别在于选举的具体过程不同，社区中关于 Raft 算法的详细讲解非常丰富，这里就不再赘述。
云溪数据库 —— ZNBase 是分布式数据库，与 OceanBase、CockroachDB、TiDB 一样都是NewSQL 家族的一员。云溪数据库具备强一致、高可用的分布式架构，能够水平扩展，提供企业级的安全特性，完全兼容 PostgreSQL 协议，能够为用户提供完整的分布式数据库解决方案。ZNBase 的整体架构如图 1 所示：
图1：ZNBase 的整体架构
ZNBase 各方面的强一致性都通过 Raft 算法实现。首先，Raft 算法保证分布式多副本之间数据强一致性以及外部读写的一致性。简而言之，ZNBase 中数据会有多个副本，这些副本存放在不同的机器上，当其中一台机器故障宕机后，数据库依旧能够对外提供服务。此外，ZNBase 会根据插入数据的键，将数据划分为多个 Range，每个 Range 上的数据均由一个 Raft Group 来维持多个副本之间数据的一致性。因此，准确地说 ZNBase 使用的是 Multi-Raft 算法。
具体来说，ZNBase 的存储层基于 RocksDB 开发，利用单机的 RocksDB，ZNBase 可以将数据快速地存储在磁盘上；在出现单机故障时，利用 Raft 算法可以快速地将数据复制到机器上。在这个过程中，数据的写入是通过 Raft 算法接口实现的，而不是直接写入 RocksDB。通过 Raft 算法，ZNBase 变成了一个分布式的键值存储系统，面对不超过集群半数的机器故障情况宕机，完全能够通过 Raft 算法自动把副本补全，做到业务对故障的无感知。
在项目开发前期，ZNBase 中的 Raft 算法采用的是开源的 etcd-raft 模块，该模块主要提供如下几点功能：
Leader 选举；
成员变更，可以细分为：增加节点、删除节点、Leader 转移等；
日志复制。
ZNBase 利用 etcd-raft 模块进行数据复制，每条数据操作都最终转化成一条 RaftLog，通过 RaftLog 复制功能，将数据操作安全可靠地同步到 Raft Group 中的每一个节点上。不过在实际操作中，根据 Raft 的协议，只需要同步复制到多数节点，即可安全地认为数据写入成功。
但是在后续的生产实践中，ZNBase 研发团队逐渐发现 etcd-raft 的模块仍存在诸多限制，于是陆续开展了如下多个方面的优化工作，具体包括：
新增 Raft 角色
新增 Leader 亲和选举
混合序列化
Raft Log 分离与定制存储
Raft 心跳与数据分离
下文将着重介绍第一点，即 ZNBase 团队根据自身业务需要为 Raft 模块新增的三种角色。
ZNBase 对 Raft 模块的改进
新增 Raft 角色
1、强同步角色
为解决部署在跨地域的多数据中心数据同步问题，达到数据在多地共同写入的效果，实现地域级别的容灾能力，ZNBase 研发团队在 etcd-raft 模块中新增了强同步角色。
具体措施如下：
为副本增加强同步标识以及配置和取消强同步标识的逻辑。
etcd-raft 模块原有的日志提交策略：Leader 得到超过半数副本(包括 Leader 自身)的投票才能提交 Raft 日志。ZNBase 在原有的过半数提交策略基础上，增加了强同步角色的日志提交策略——日志提交还需要得到所有强同步副本的投票。
为强同步角色设计了如图 2 所示的故障识别与处理机制：通过心跳超时机制识别强同步故障，提交日志时忽略故障的强同步角色，并将故障信息录入数据库日志并告知用户。
为强同步角色的心跳超时时间增加热更新功能。
图2 强同步角色的处理逻辑
经过以上四点改造后，etcd-raft 模块新增强同步角色，能够实现如下功能：
允许用户为指定副本配置或取消强同步角色，不影响强同步角色所在副本的原有特性。例如对全能型副本配置强同步角色后，该副本依然存储 Raft 日志和用户数据，参与投票，参与 Leader 选举，当选为 Leader 可提供读写服务，Follower 时可提供非一致性读。
强同步角色的数据与 leader 保持同步。
允许用户配置强同步角色的心跳超时时间。如果强同步角色发生故障，Raft 集群将在该超时时间后恢复写入功能，故障期间的写入也会在超时时间后提交。Raft会在识别到强同步角色故障后暂时取消强同步标记，并在该强同步角色故障解决后自动恢复。强同步角色故障和恢复的信息对用户可见。
允许用户在 SQL 终端查询强同步角色的配置状态。
2、只读型角色
由于 ZNBase 具备 HTAP 的特性，因此需要在 Raft Group 中增加一种相对独立的特殊副本，对外仅提供读服务(例如将该类型副本的存储引擎替换成列存引擎)以实现 OLAP 的功能。为了在 Raft Group 中增加这种特殊副本，同时不影响原有的集群特性，ZNBase 研发团队在 Raft 中设计了一种新的只读型角色。
具体实现措施如下：
增加只读型角色标识，增加只读型角色的创建、删除、重平衡逻辑。
增加只读型副本接收到请求后读取数据的逻辑：如果只读型角色的时间戳不小于请求的时间戳，则提供读服务；否则会重试多次，重试达到限制后会将读取超时错误返回到 SQL 终端。
为只读型副本的时间戳更新间隔、读取时的最大重试次数等参数增加热更新功能。
etcd-raft 模块新增只读型角色后，能够实现如下功能：
允许用户在指定位置创建、删除或移动只读型角色。只读型角色支持基于负载均衡的重平衡功能，移动到压力相对较小的节点。
该角色对外仅提供读服务，存储 Raft 日志和用户数据，不参与投票，不参与 Leader 选举，可提供读服务。
允许用户配置只读型副本的时间戳更新间隔、读取时的最大重试次数，可以用于对只读型副本的读取性能进行调优。
允许用户在 SQL 终端查询只读型角色的配置情况。
3、日志型角色
ZNBase 不支持在两数据中心三副本部署模式下提供双活模式，无论如何部署副本的位置，总有一个数据中心拥有过半数的副本。当拥有过半数副本的数据中心故障时，另一个数据中心由于所拥有的可用副本数不满足过半数，会导致 ZNBase 无法对外正常提供服务。为解决此类问题，提高 ZNBase 的容灾能力，同时充分利用和整合资源，避免出现资源闲置造成的浪费现象，提升双活数据中心的服务能力，项目团队在 etcd-raft 模块增加了日志型角色。
具体实现措施如下：
日志型副本参与 Leader 选举，拥有投票权，并且可以成为 Leader。在普通副本缺少最新日志的故障场景下，为了恢复集群的可用性，需要日志型副本当选为 Leader，并向其他副本追加日志，使得该副本拥有最新的日志。然后发起 Leader 转移，拥有最新日志的副本当选为 Leader 和 Leaseholder，完成集群恢复。
日志型副本不能发送快照。由于日志型副本不含用户数据，若发送快照将导致其他副本丢失数据，因此禁止日志型副本发送快照。
日志型副本不能成为 LeaseHolder。禁止从日志型副本读取数据，且在日志型副本成为Leader 的情况下，在其他副本拥有最新日志后，将立即转移 Leader 到该副本上。
日志型副本保留日志。日志型副本的日志可用于故障恢复，因此延长其日志保留时间。原有的日志清理策略为当可清理的日志 index 数量大于等于 100 或实际大小大于等于 64KB 时，执行日志清理操作。当出现节点宕机时，待清理的日志超过 4MB 执行日志清理操作。日志型副本的日志清理策略为:将日志清理请求按小时打包、延迟处理，默认清理时间值为24，即将日志清理请求延迟24小时处理，达到日志保留的效果。用户可配置清理时间值，可配置范围是[-1, MaxInt]，若配置为 -1 则表示不保留日志，按照原来的逻辑执行清理操作。
日志型副本异地重启。日志型副本异地重启时会因尝试提交心跳消息携带的 Commit 值而宕机。修改 follower 处理心跳的逻辑，如果日志型 follower 收到心跳消息的 Commit 值比实际的 lastIndex 值大，就将心跳回复消息的 Reject 字段置为 true、RejectHint 字段置为实际的 lastIndex。Leader 收到 Reject 为 true 的心跳回复消息时，将对应 follower 副本 progress 的 Match 和 Next 更新为实际值，并向该副本追加日志，将其丢失的日志补全。
针对日志型角色增加 Logonly 语法支持，使用 Alter 语句配置样例如下，表 t 拥有 3 个副本，其中将 2 个全能型副本放在北京和济南，日志型副本放在天津：
ALTER TABLE t CONFIGURE ZONE USING num_replicas=2, num_logonlys=1, constraints='{"+region=beijing": 1,"+region=jinan": 1}', logonly_constraints='{"+region=tianjin":1}';
以两中心三副本(一个全能型、一个强同步、一个日志型)模式进行部署为例，全能型副本与强同步副本分别存放在 DC-1 与 DC-2 的高配机器(或多数机器)中，日志型副本存放在 DC-1 或 DC-2 的低配机器(或少量机器)中，日志增量复制到另一个数据中心的低配机器(或少量机器)。若遭遇数据中心级别的故障，在失去两个副本(一个全能型、一个日志型)后，在另一个数据中心手动启动存放日志型副本的节点，该日志型副本含有基于增量复制得到的日志数据。
遭遇数据中心级别的故障时的容灾处理(Node7 的日志型副本需要手动重启)
通过给 Raft 算法增加 3 种新的角色，ZNBase 在跨地域集群容灾、支持 OLAP 等方面的能力得到了显著加强。
小结
上文介绍了 Raft 一致性算法在分布式 NewSQL 数据库 ZNBase 中发挥的重要作用，以及 ZNBase 项目团队根据自身业务特性与需求，在 Raft 算法中新设计的三种角色，从而提高了 ZNBase 的异地容灾和 HTAP 的能力。除了新增 Raft 角色以外，ZNBase 研发团队还针对 Raft 模块做了新增 Leader 亲和选举、混合序列化、Raft Log 分离与定制存储和 Raft 心跳与数据分离等优化改进，受篇幅限制，我们将在接下来的第二部分中详细解析这四大改进。
第二部分
云溪数据库 ZNBase 是由浪潮开源的一款 NewSQL 分布式数据库，具备 HTAP 特性，拥有强一致、高可用的分布式架构。其中，ZNBase 各方面的强一致性都依靠 Raft 算法实现。我们在第一部分中介绍了 Raft 一致性算法在分布式数据库中发挥的重要作用，以及 ZNBase 根据自身需求对 Raft 算法进行了优化改造，为其新增了三种角色设计。本文将继续介绍 ZNBase 研发团队在落地 Raft 模块的过程中对其进行的其他优化改进。
前文提到，在项目开发前期，ZNBase 中的 Raft 算法采用的是开源的 etcd-raft 模块，但是在后续的生产实践中，ZNBase 研发团队逐渐发现 etcd-raft 的模块仍存在诸多限制，于是陆续开展了如下多个方面的优化工作，具体包括：
新增 Raft 角色
新增 Leader 亲和选举
混合序列化
Raft Log 分离与定制存储
Raft 心跳与数据分离
下文将着重介绍新增 Leader 亲和选举、混合序列化、Raft Log 分离与定制存储、Raft 心跳与数据分离这四大优化改进。
ZNBase 对 Raft 模块的改进
新增 Leader 亲和选举
ZNBase 基于 Raft 算法对外提供强一致，对于存储的所有读写操作，均需要通过 Raft Leader 处理。在以多地多数据中心模式部署的情况下，客户端希望经常访问的数据经过本地网络就可以访问到 Raft Leader，对数据进行访问，避免跨地区访问较高的网络延迟。因此，项目团队针对 ZNBase 中的 etcd-raft 模块为其增加了亲和选举功能，即选举 Raft Leader 时，根据亲和配置干预选举，使亲和性更高的副本当选为 Raft Leader。
在原本的 etcd-raft 模块中，进行 Leader 选举之前，Raft group 中所有副本均为 Follower，当某个节点的选举计时器超时后会发起一次选举。NewSQL 中选举计时器超时的时间单位为 Tick，每个 Tick 默认是 200ms (defaultRaftTickInterval)，默认选举超时 Ticks 为 15 (defaultRaftElectionTimeoutTicks)，最后得出超时时间为
[15 * 200ms, (2*15 – 1) * 200ms] == [3000ms, 5800ms]
区间内随机的200ms的倍数。由于选举超时时间是完全随机的，那么优先发起选举的节点也是完全随机的。
基于原有逻辑，研发团队提出了“增加一轮选举超时时间”的策略(如图 3 所示)：
图3：增加一轮选举超时时间示意图
即当选举计时器超时后，在发起选举前对亲和配置进行检查，检查的策略如下：
如果没有亲和配置，直接发起选举。
如果有亲和配置，亲和配置与当前节点 locality 标签相符，得出当前节点为亲和节点，直接发起选举。
如果有亲和配置，亲和配置与当前节点 locality 标签不符，得出当前节点为非亲和节点，重置选举计时器，不发起选举，等待下一轮选举超时后，即使不是亲和节点也立即发起选举。
等待一轮选举超时后，即使不是亲和节点也立即发起选举的目的是：保证集群一定的可用性，一般情况下，在两次选举计时器超时间隔内可以选出 Raft Leader。考虑到可能存在的其他极端情况，提出“控制随机选举超时时间范围”的补充策略(如图 4 所示)，即在选举超时时间的随机范围内，亲和节点选举超时时间的区间小于非亲和节点，亲和节点会先超时并发起选举。通过约束亲和与非亲和副本的随机选举超时时间范围，使得亲和副本选举计时器先超时，提高优先发起 Raft Leader 选举的概率。这样就保证了亲和副本比非亲和副本先发起一轮选举(在亲和副本能当选为 Leader 时，优先当选为 Leader)，即使亲和的副本由于日志较旧，无法当选为 Leader, 非亲和的副本在两次选举计时器超时时间内能当选为 Leader，保障了可用性。
图4 控制选举超时时间范围图
亲和选举对 Raft 的影响有：增加一轮选举超时时间可以看似为一次选举失败，选举计时器重置，等待下一次选举；控制随机选举超时时间范围是在原有许可范围内，对亲和与非亲和的节点进行更细的范围划分，划分后仍是在原有的范围内。
混合序列化
在 etcd-raft 模块中节点之间通过 gRPC 协议实现通信，序列化方式则采用 protobuf 进行序列化，相对 colfer 而言，protobuf 是一种较慢的序列化方式。使用给定配置的机器(Intel Core i5 CPU@2.9 GHz、内存 8GB、Go1.15.7 darwin/amd64)利用 protobuf、gogoprotobuf 和 colfer 协议分别对给定数据进行了在序列化和反序列化，详细的实验数据如下表所示：
表1 protobuf、gogoprotobuf 以及 colfer 协议性能对比
为了提高序列化的效率，根据实验结果采用 protobuf+colfer 的混合序列化方式，当需要序列化操作时，调用 protobuf 的序列化方式，当将数据进行序列化时则采用 colfer 方式加快序列化的效率，这比单独使用 protobuf 序列化提高了 40% 的性能，表 2 是 gogoprotobuf 和混合序列化在相同测试环境(Intel Core i7 CPU@1.8GHz × 4 、内存 8G、Go1.14 linux/amd64)下的性能对比。
表2 gogoprotobuf和混合序列化性能对比
Raft Log 分离与定制存储
在 etcd-raft 模块中，Raft Group 中的 Leader 节点接收客户端发来的 Request，将 Request 封装成 Raft Entry(Raft Log 的基本组成单元)追加到本地，并通过 gRPC 将 Raft Entry 发送给 Raft Group 中其他 Follower 节点，当 Follower 节点收到 Raft Entry 后进行追加、刷盘以及回复处理结果的同时，Leader 将本地 Raft Entry 进行刷盘，两者同步进行。等 Leader 节点收到过半数节点的肯定回复后，提交 Raft Entry 并将其应用到状态机(将 Raft Entry 中包含的业务数据进行持久化)，然后将处理结果返回客户端。
从上面的分析中可以看出 Raft Log 在副本之间达成共识、节点重启以及节点故障恢复等环节都起到至关重要的作用，Raft Log 与业务数据共同存储在同一个 RocksDB 中，在查询高峰期必然会发生磁盘 I/O 资源争抢，增加查询等待时延，降低数据库的整体性能。在 TPCC 场景下进行了 Raft Log 与业务数据写入量的测试，测试场景如下：在物理机(CPU：6240，72 核， 内存:384G，系统硬盘：480G，数据盘：375G+SSD，硬盘:2T*7)上启动单节点 ZNBase 服务，系统稳定后 init 6000 仓 TPCC 数据，观察整个过程中业务数据与 Raft Log 写入量的大小，测试结果如表 3 所示。
表3 TPCC 初始化过程数据量统计
同时开展了 TPCC 场景下针对 Raft Log 各项操作数量的测试，测试场景如下：启动 3 个节点的 ZNBase 集群，系统稳定后 init 40 仓 TPCC 数据，观察网关节点在整个初始化过程中 Raft Log 各项操作数量的变化，测试结果如表 4 所示。将 RaftEntryCache 的大小从 16MiB 增加到 1GiB 后，相同场景下 Term 与 Entry 的查询数量下降到 0。
表4 TPCC 初始化过程Raft Log各项操作统计
根据上述测试以及测试结果，可将 ZNBase 中 Raft Log 的操作特点总结如下：
在正常运行过程中，插入和删除操作是最多的且数量也很接近，说明 Raft Log 持久化的时间很短。查询 RaftLogSize 也是较为常规操作，其他操作都是在特殊场景下触发的，几乎可以忽略不计。
查询 Term 与查询 Entry 的操作次数取决于 RaftEntryCache 的大小，是由 ZNBase 内部实现机制决定的，Entry和Term的查询一般先去Unstable中查找，查找不到再去RaftEntryCache中查找，还是查找不到就到底层存储中查找。通常情况下RaftEntryCache大小设置合理的话可以命中所有查找。
ZNBase 实际运行过程中产生的 Raft Log 比真正持久化的业务数据多很多(5~10倍)，而且只要数据库持续运行(即使没有任何用户查询)就会源源不断的产生 Raft Log。Raft Log 是用户数据的载体，为了保证数据完整性和一致性 Raft Log 必须持久化。
ZNBase 中存储 raft Log 的引擎面临的真正挑战是频繁写入、删除以及短暂的存储给系统带来的性能损耗。
通过对 ZNBase 中 Raft Log 操作场景的详细分析，总结 Raft Log 存储引擎应该满足如下特征：
尽可能将待查询数据保存在内存中，减少不必要磁盘I/O;
写入的数据能够及时落盘，保证故障恢复后数据的完整性和一致性；
能够及时的清理被删除数据或是延迟清理被删除数据，减少不必要的资源占用。
针对这个问题，业内分别有不同的解决方案。以 TiDB 为例，目前 TiDB 的解决方案是：每个 TiKV 实例中有两个 RocksDB 实例，一个用于存储 Raft 日志(通常被称为 raftdb)，另一个用于存储用户数据以及 MVCC 信息(通常被称为 kvdb)。同时，TiDB 团队还开发了基于 RocksDB 的高性能单机 Key-Value 存储引擎 —— Titan。
而在 ZNBase 中直接使用 RocksDB 来存储 Raft Log 是不合适的，不能很好地满足 Raft Log 的具体使用场景。RocksDB 内部采用 LSMTree 存储数据，在 Raft Log 频繁写入快速删除并且还会持续进行随机查询的场景下，造成严重读放大和写放大，不能够充分发挥出 RocksDB 的优势，也对系统整体性能造成不利影响。
ZNBase 研发团队在详细调研分析 LevelDB、RocksDB、Titan、BadgerDB、FlashKey 以及 Aerospike 的具体架构与特征后，决定在 BadgerDB v2.0 的基础上进行定制优化，作为ZNBase 中 Raft Log 的专用存储引擎。Raft Log 定制存储实现了以下基本功能：
Raft Log 的批量写入与持久化；
Raft Log 的顺序删除与延迟 GC；
Raft Log 的迭代查询，包括：RaftLogSize 查询、Term 查询、LastIndex 查询以及 Entry 查询；
相关 Metrics 的可视化；
多引擎场景下的用户数据完整与一致保证策略。
ZNBase 中 Raft Log 定制存储整体部署架构如图 5 所示：
图 5：Raft Log 定制存储整体部署架构
部署时 BadgerDB 需要与 RocksDB 并列进行部署，即一个 Node 上部署相等数量的 RocksDB 实例和 BadgerDB 实例(由目前 ZNBase 中副本平衡策略所决定)。
查询请求的大致处理流程是先将 Raft Log 写入 BadgerDB，等待集群过半数节点达成共识后，再将 Raft Log 应用到状态机，即将 Raft Log 转化成用户数据写入到 RocksDB，用户写入成功后再将 BadgerDB 中已应用的 Raft Log 删除，同时将状态数据更新到 RocksDB 中。
ZNBase 中 Raft Log 定制存储的写、读流程如图 6 所示：
图 6：RaftLog 定制存储写、读流程
由于Raft Log 定制存储采用 Key-Value 分离的策略，完整的 Key-Value 数据首先写入 VLog 并落盘(如果是删除操作则在落盘成功后由 IfDiscardStats 更新内存中维护各 VLog File 的删除数据的统计信息，这些统计信息也会定期落盘，避免了 BadgerDB 中 SSTable 压缩不及时导致统计信息滞后的问题)，然后将 Key 以及元数据信息写入 Memtable(skiplist)。将 Level 0 SSTable 放入内存，同时将需要频繁查询的信息(RaftLogSize、Term 等)记录到元数据放入内存，加快随机读取的效率，减少不必要的 I/O。
已删除 Key 的清理依赖 SSTable 的压缩，对应 Value 的清理则需要 ZNBase 周期性调用接口，首先根据访问 IfDiscardStats 在内存中维护的 VLog file 的 discardStats，对备选文件进行排序，顺序遍历进行采样，若可以进行 GC 则遍历 VLog File 中的 Entry，同时到 Mentable (或 SSTable)查看最新元数据信息确定是否需要进行重写，需要重写则写入新的 VLog File，不需要则直接跳过，Raft Log 定制存储中 GC 处理流程如图 7 所示：
图 7 RaftLog 定制存储 VLog GC 流程
在将 Raft Log 进行独立储存后，必须要考虑多个存储引擎数据保持一致性的策略。Raft Log 存在的目的是为了保证业务数据的完整，因此在 Raft Log 与业务数据分开存储后不追求两者完全一致，而是 Raft Log 保持一定 的“冗余”。具体策略是每个 range 上的 Raft log 在被应用到状态机之后不会立刻被删除，会保留一段时间(例如：默认每个 range 默认保留 50 个 Raft Entry)，进而满足用户数据完整性的各项要求。同时，如果发现所需要的 Raft Log 在本地存储中找不到，则发送消息给 Leader 去请求，通过 MsgApp 或是 Snapshot 获取所需的 Raft Log。
ZNBase 研发团队完成上述优化后，开展了“迭代查询性能对比测试”与“TPCC 场景性能测试”。在“迭代查询性能对比测试”中，测试场景如下：启动单机单节点 ZNBase 服务，系统稳定运行后 init 40 仓 TPCC 数据，记录迭代器查询 RaftLogSize 与 Term 的总耗时。Raft Log 分别存储在 RocksDB、BadgerDB 以及 Raft Log 定制存储中，其中 ValueThreshold 设置为1KB，其他设置均采用默认值。
表5 迭代查询测试结果汇总
从上述测试结果来看，在对 Badger 迭代器进行优化后，针对元数据的迭代查询速率得到大幅提升，相比 RocksDB 迭代查询延迟降低了约 90%。
在“TPCC场景性能测试”中，测试场景如下：在物理机(CPU：6240 72核 内存:384G 系统硬盘：480G 数据盘：375G+SSD硬盘:2T*7)启动单节点 ZNBase 服务，系统稳定后 init 6000 仓 TPCC 数据，观察整个过程中相应监控指标。
表6 TPCC 压测监控数据汇总表
从上述测试结果来看，Raft Log 采用定制存储后，raft Log 提交延迟下降约 60%，raft Log 应用延迟下降约 25%，RocksDB 读放大下降约 60%(高负载)，同时没有明显增加资源消耗。
综上，利用键值分离的思想优化 LSM 树，借助索引模块提升迭代查询性能，使用统计前置的策略提升系统 GC 的效率，能够很好满足 ZNBase 中 Raft Log 在各种操作场景下的性能要求。
Raft 心跳与数据分离
在 etcd-raft 模块的实现逻辑中，负责处理节点间心跳请求以及负责处理用户、系统请求的Processor 共享同一个资源池，由于储存消息请求的队列采用 FIFO 执行方式，这样就可能会导致所有的资源被用户、系统请求占用从而导致节点间心跳请求被延迟等待处理，过长的延迟处理时间可能会导致集群之间由于无法及时响应心跳请求出现节点失效情况的发生。
因此，为了保证集群的稳定性，在此将 Raft Processor 的处理逻辑进行分离，负责处理节点间心跳请求的 Processor 将被分配一定份额的资源，这一部分资源只用于 Processor 处理节点间心跳消息。
分离 Raft Scheduler 为 Tick、ReadyRequest(Ready 与 Request )两类，两类 Scheduler 各自拥有自己的资源池(Gouroutine)以及 RangeID 消息队列，同时对 Raft Scheduler 处理消息流程进行分离，将处理 tick 请求的流程从之前的总流程中拆分，从而有效降低 Raft 心跳延迟，测试结果显示优化后 Tick 处理的平均延迟下降 30%，具体如下图所示：
Tick 处理的平均延迟(优化前)
Tick 处理的平均延迟(优化后)
总结
本系列文章介绍了 Raft 一致性算法在分布式 NewSQL 数据库 ZNBase 中发挥的重要作用，以及 ZNBase 项目团队根据自身业务特性与需求，在落地 Raft 一致性协议的过程中对其做出的五大优化改造，希望能对开发者进一步学习 Raft 一致性协议在分布式数据库场景下的实践过程有所帮助。
关于 ZNBase 的更多详情可以查看：
官方代码仓库：https://gitee.com/ZNBase/zn-kvs
ZNBase 官网：http://www.znbase.com/
对相关技术或产品有任何问题欢迎提 issue 或在社区中留言讨论。同时欢迎更多对分布式数据库感兴趣的开发者加入我们的团队！
全文完。
第一部分
导读
云溪数据库 ZNBase 是由浪潮开源的一款 NewSQL 分布式数据库，具备 HTAP 特性，拥有强一致、高可用的分布式架构。对于一个高可用的分布式系统来说，为了保障不同集群不同节点的数据一致，一致性算法尤为重要。Raft 是一种管理日志复制的分布式一致性算法，包括 ZNBase 在内的很多分布式系统都采用 Raft 作为底层的一致性协议。本系列文章将为大家介绍 Raft 一致性算法在 ZNBase 中的落地实践，并深入解析 ZNBase 技术团队根据自身业务需求对 Raft 协议做出的五大优化改进。
Raft 简介
Raft 作为一种管理日志复制的分布式一致性算法，由斯坦福大学的 Diego Ongaro 和 John Ousterhout 在论文中提出。在 Raft 出现之前，Paxos 一直是分布式一致性算法的标准。但 Paxos 相对难以理解，Raft 的设计目标就是简化 Paxos，使得一致性算法更容易理解和实现。
Paxos 和 Raft 都是分布式一致性算法，其过程如同投票选举领袖(Leader)，参选者(Candidate)需要说服大多数投票者(Follower)给他投票，一旦选举出领袖，就由领袖发号施令。Paxos 和 Raft 的区别在于选举的具体过程不同，社区中关于 Raft 算法的详细讲解非常丰富，这里就不再赘述。
ZNBase 中的 Raft 算法
云溪数据库 —— ZNBase 是分布式数据库，与 OceanBase、CockroachDB、TiDB 一样都是NewSQL 家族的一员。云溪数据库具备强一致、高可用的分布式架构，能够水平扩展，提供企业级的安全特性，完全兼容 PostgreSQL 协议，能够为用户提供完整的分布式数据库解决方案。ZNBase 的整体架构如图 1 所示：
图1：ZNBase 的整体架构
ZNBase 各方面的强一致性都通过 Raft 算法实现。首先，Raft 算法保证分布式多副本之间数据强一致性以及外部读写的一致性。简而言之，ZNBase 中数据会有多个副本，这些副本存放在不同的机器上，当其中一台机器故障宕机后，数据库依旧能够对外提供服务。此外，ZNBase 会根据插入数据的键，将数据划分为多个 Range，每个 Range 上的数据均由一个 Raft Group 来维持多个副本之间数据的一致性。因此，准确地说 ZNBase 使用的是 Multi-Raft 算法。
具体来说，ZNBase 的存储层基于 RocksDB 开发，利用单机的 RocksDB，ZNBase 可以将数据快速地存储在磁盘上；在出现单机故障时，利用 Raft 算法可以快速地将数据复制到机器上。在这个过程中，数据的写入是通过 Raft 算法接口实现的，而不是直接写入 RocksDB。通过 Raft 算法，ZNBase 变成了一个分布式的键值存储系统，面对不超过集群半数的机器故障情况宕机，完全能够通过 Raft 算法自动把副本补全，做到业务对故障的无感知。
在项目开发前期，ZNBase 中的 Raft 算法采用的是开源的 etcd-raft 模块，该模块主要提供如下几点功能：
Leader 选举；
成员变更，可以细分为：增加节点、删除节点、Leader 转移等；
日志复制。
ZNBase 利用 etcd-raft 模块进行数据复制，每条数据操作都最终转化成一条 RaftLog，通过 RaftLog 复制功能，将数据操作安全可靠地同步到 Raft Group 中的每一个节点上。不过在实际操作中，根据 Raft 的协议，只需要同步复制到多数节点，即可安全地认为数据写入成功。
但是在后续的生产实践中，ZNBase 研发团队逐渐发现 etcd-raft 的模块仍存在诸多限制，于是陆续开展了如下多个方面的优化工作，具体包括：
新增 Raft 角色
新增 Leader 亲和选举
混合序列化
Raft Log 分离与定制存储
Raft 心跳与数据分离
下文将着重介绍第一点，即 ZNBase 团队根据自身业务需要为 Raft 模块新增的三种角色。
ZNBase 对 Raft 模块的改进
新增 Raft 角色
1、强同步角色
为解决部署在跨地域的多数据中心数据同步问题，达到数据在多地共同写入的效果，实现地域级别的容灾能力，ZNBase 研发团队在 etcd-raft 模块中新增了强同步角色。
具体措施如下：
为副本增加强同步标识以及配置和取消强同步标识的逻辑。
etcd-raft 模块原有的日志提交策略：Leader 得到超过半数副本(包括 Leader 自身)的投票才能提交 Raft 日志。ZNBase 在原有的过半数提交策略基础上，增加了强同步角色的日志提交策略——日志提交还需要得到所有强同步副本的投票。
为强同步角色设计了如图 2 所示的故障识别与处理机制：通过心跳超时机制识别强同步故障，提交日志时忽略故障的强同步角色，并将故障信息录入数据库日志并告知用户。
为强同步角色的心跳超时时间增加热更新功能。
图2 强同步角色的处理逻辑
经过以上四点改造后，etcd-raft 模块新增强同步角色，能够实现如下功能：
允许用户为指定副本配置或取消强同步角色，不影响强同步角色所在副本的原有特性。例如对全能型副本配置强同步角色后，该副本依然存储 Raft 日志和用户数据，参与投票，参与 Leader 选举，当选为 Leader 可提供读写服务，Follower 时可提供非一致性读。
强同步角色的数据与 leader 保持同步。
允许用户配置强同步角色的心跳超时时间。如果强同步角色发生故障，Raft 集群将在该超时时间后恢复写入功能，故障期间的写入也会在超时时间后提交。Raft会在识别到强同步角色故障后暂时取消强同步标记，并在该强同步角色故障解决后自动恢复。强同步角色故障和恢复的信息对用户可见。
允许用户在 SQL 终端查询强同步角色的配置状态。
2、只读型角色
由于 ZNBase 具备 HTAP 的特性，因此需要在 Raft Group 中增加一种相对独立的特殊副本，对外仅提供读服务(例如将该类型副本的存储引擎替换成列存引擎)以实现 OLAP 的功能。为了在 Raft Group 中增加这种特殊副本，同时不影响原有的集群特性，ZNBase 研发团队在 Raft 中设计了一种新的只读型角色。
具体实现措施如下：
增加只读型角色标识，增加只读型角色的创建、删除、重平衡逻辑。
增加只读型副本接收到请求后读取数据的逻辑：如果只读型角色的时间戳不小于请求的时间戳，则提供读服务；否则会重试多次，重试达到限制后会将读取超时错误返回到 SQL 终端。
为只读型副本的时间戳更新间隔、读取时的最大重试次数等参数增加热更新功能。
etcd-raft 模块新增只读型角色后，能够实现如下功能：
允许用户在指定位置创建、删除或移动只读型角色。只读型角色支持基于负载均衡的重平衡功能，移动到压力相对较小的节点。
该角色对外仅提供读服务，存储 Raft 日志和用户数据，不参与投票，不参与 Leader 选举，可提供读服务。
允许用户配置只读型副本的时间戳更新间隔、读取时的最大重试次数，可以用于对只读型副本的读取性能进行调优。
允许用户在 SQL 终端查询只读型角色的配置情况。
3、日志型角色
ZNBase 不支持在两数据中心三副本部署模式下提供双活模式，无论如何部署副本的位置，总有一个数据中心拥有过半数的副本。当拥有过半数副本的数据中心故障时，另一个数据中心由于所拥有的可用副本数不满足过半数，会导致 ZNBase 无法对外正常提供服务。为解决此类问题，提高 ZNBase 的容灾能力，同时充分利用和整合资源，避免出现资源闲置造成的浪费现象，提升双活数据中心的服务能力，项目团队在 etcd-raft 模块增加了日志型角色。
具体实现措施如下：
日志型副本参与 Leader 选举，拥有投票权，并且可以成为 Leader。在普通副本缺少最新日志的故障场景下，为了恢复集群的可用性，需要日志型副本当选为 Leader，并向其他副本追加日志，使得该副本拥有最新的日志。然后发起 Leader 转移，拥有最新日志的副本当选为 Leader 和 Leaseholder，完成集群恢复。
日志型副本不能发送快照。由于日志型副本不含用户数据，若发送快照将导致其他副本丢失数据，因此禁止日志型副本发送快照。
日志型副本不能成为 LeaseHolder。禁止从日志型副本读取数据，且在日志型副本成为Leader 的情况下，在其他副本拥有最新日志后，将立即转移 Leader 到该副本上。
日志型副本保留日志。日志型副本的日志可用于故障恢复，因此延长其日志保留时间。原有的日志清理策略为当可清理的日志 index 数量大于等于 100 或实际大小大于等于 64KB 时，执行日志清理操作。当出现节点宕机时，待清理的日志超过 4MB 执行日志清理操作。日志型副本的日志清理策略为:将日志清理请求按小时打包、延迟处理，默认清理时间值为24，即将日志清理请求延迟24小时处理，达到日志保留的效果。用户可配置清理时间值，可配置范围是[-1, MaxInt]，若配置为 -1 则表示不保留日志，按照原来的逻辑执行清理操作。
日志型副本异地重启。日志型副本异地重启时会因尝试提交心跳消息携带的 Commit 值而宕机。修改 follower 处理心跳的逻辑，如果日志型 follower 收到心跳消息的 Commit 值比实际的 lastIndex 值大，就将心跳回复消息的 Reject 字段置为 true、RejectHint 字段置为实际的 lastIndex。Leader 收到 Reject 为 true 的心跳回复消息时，将对应 follower 副本 progress 的 Match 和 Next 更新为实际值，并向该副本追加日志，将其丢失的日志补全。
针对日志型角色增加 Logonly 语法支持，使用 Alter 语句配置样例如下，表 t 拥有 3 个副本，其中将 2 个全能型副本放在北京和济南，日志型副本放在天津：
ALTER TABLE t CONFIGURE ZONE USING num_replicas=2, num_logonlys=1, constraints='{"+region=beijing": 1,"+region=jinan": 1}', logonly_constraints='{"+region=tianjin":1}';
以两中心三副本(一个全能型、一个强同步、一个日志型)模式进行部署为例，全能型副本与强同步副本分别存放在 DC-1 与 DC-2 的高配机器(或多数机器)中，日志型副本存放在 DC-1 或 DC-2 的低配机器(或少量机器)中，日志增量复制到另一个数据中心的低配机器(或少量机器)。若遭遇数据中心级别的故障，在失去两个副本(一个全能型、一个日志型)后，在另一个数据中心手动启动存放日志型副本的节点，该日志型副本含有基于增量复制得到的日志数据。
遭遇数据中心级别的故障时的容灾处理(Node7 的日志型副本需要手动重启)
通过给 Raft 算法增加 3 种新的角色，ZNBase 在跨地域集群容灾、支持 OLAP 等方面的能力得到了显著加强。
小结
上文介绍了 Raft 一致性算法在分布式 NewSQL 数据库 ZNBase 中发挥的重要作用，以及 ZNBase 项目团队根据自身业务特性与需求，在 Raft 算法中新设计的三种角色，从而提高了 ZNBase 的异地容灾和 HTAP 的能力。除了新增 Raft 角色以外，ZNBase 研发团队还针对 Raft 模块做了新增 Leader 亲和选举、混合序列化、Raft Log 分离与定制存储和 Raft 心跳与数据分离等优化改进，受篇幅限制，我们将在接下来的第二部分中详细解析这四大改进。
第二部分
云溪数据库 ZNBase 是由浪潮开源的一款 NewSQL 分布式数据库，具备 HTAP 特性，拥有强一致、高可用的分布式架构。其中，ZNBase 各方面的强一致性都依靠 Raft 算法实现。我们在第一部分中介绍了 Raft 一致性算法在分布式数据库中发挥的重要作用，以及 ZNBase 根据自身需求对 Raft 算法进行了优化改造，为其新增了三种角色设计。本文将继续介绍 ZNBase 研发团队在落地 Raft 模块的过程中对其进行的其他优化改进。
前文提到，在项目开发前期，ZNBase 中的 Raft 算法采用的是开源的 etcd-raft 模块，但是在后续的生产实践中，ZNBase 研发团队逐渐发现 etcd-raft 的模块仍存在诸多限制，于是陆续开展了如下多个方面的优化工作，具体包括：
新增 Raft 角色
新增 Leader 亲和选举
混合序列化
Raft Log 分离与定制存储
Raft 心跳与数据分离
下文将着重介绍新增 Leader 亲和选举、混合序列化、Raft Log 分离与定制存储、Raft 心跳与数据分离这四大优化改进。
ZNBase 对 Raft 模块的改进
新增 Leader 亲和选举
ZNBase 基于 Raft 算法对外提供强一致，对于存储的所有读写操作，均需要通过 Raft Leader 处理。在以多地多数据中心模式部署的情况下，客户端希望经常访问的数据经过本地网络就可以访问到 Raft Leader，对数据进行访问，避免跨地区访问较高的网络延迟。因此，项目团队针对 ZNBase 中的 etcd-raft 模块为其增加了亲和选举功能，即选举 Raft Leader 时，根据亲和配置干预选举，使亲和性更高的副本当选为 Raft Leader。
在原本的 etcd-raft 模块中，进行 Leader 选举之前，Raft group 中所有副本均为 Follower，当某个节点的选举计时器超时后会发起一次选举。NewSQL 中选举计时器超时的时间单位为 Tick，每个 Tick 默认是 200ms (defaultRaftTickInterval)，默认选举超时 Ticks 为 15 (defaultRaftElectionTimeoutTicks)，最后得出超时时间为
[15 * 200ms, (2*15 – 1) * 200ms] == [3000ms, 5800ms]
区间内随机的200ms的倍数。由于选举超时时间是完全随机的，那么优先发起选举的节点也是完全随机的。
基于原有逻辑，研发团队提出了“增加一轮选举超时时间”的策略(如图 3 所示)：
图3：增加一轮选举超时时间示意图
即当选举计时器超时后，在发起选举前对亲和配置进行检查，检查的策略如下：
如果没有亲和配置，直接发起选举。
如果有亲和配置，亲和配置与当前节点 locality 标签相符，得出当前节点为亲和节点，直接发起选举。
如果有亲和配置，亲和配置与当前节点 locality 标签不符，得出当前节点为非亲和节点，重置选举计时器，不发起选举，等待下一轮选举超时后，即使不是亲和节点也立即发起选举。
等待一轮选举超时后，即使不是亲和节点也立即发起选举的目的是：保证集群一定的可用性，一般情况下，在两次选举计时器超时间隔内可以选出 Raft Leader。考虑到可能存在的其他极端情况，提出“控制随机选举超时时间范围”的补充策略(如图 4 所示)，即在选举超时时间的随机范围内，亲和节点选举超时时间的区间小于非亲和节点，亲和节点会先超时并发起选举。通过约束亲和与非亲和副本的随机选举超时时间范围，使得亲和副本选举计时器先超时，提高优先发起 Raft Leader 选举的概率。这样就保证了亲和副本比非亲和副本先发起一轮选举(在亲和副本能当选为 Leader 时，优先当选为 Leader)，即使亲和的副本由于日志较旧，无法当选为 Leader, 非亲和的副本在两次选举计时器超时时间内能当选为 Leader，保障了可用性。
图4 控制选举超时时间范围图
亲和选举对 Raft 的影响有：增加一轮选举超时时间可以看似为一次选举失败，选举计时器重置，等待下一次选举；控制随机选举超时时间范围是在原有许可范围内，对亲和与非亲和的节点进行更细的范围划分，划分后仍是在原有的范围内。
混合序列化
在 etcd-raft 模块中节点之间通过 gRPC 协议实现通信，序列化方式则采用 protobuf 进行序列化，相对 colfer 而言，protobuf 是一种较慢的序列化方式。使用给定配置的机器(Intel Core i5 CPU@2.9 GHz、内存 8GB、Go1.15.7 darwin/amd64)利用 protobuf、gogoprotobuf 和 colfer 协议分别对给定数据进行了在序列化和反序列化，详细的实验数据如下表所示：
表1 protobuf、gogoprotobuf 以及 colfer 协议性能对比
benchmark | iter | time/iter | bytes/op | allocs/op |
ProtobufMarshal | 1761278 | 674 ns/op | 52 | 152 |
ProtobufUnmarshal | 1916198 | 627 ns/op | 52 | 192 |
GogoprotobufMarshal | 9089631 | 131 ns/op | 53 | 64 |
GogoprotobufUnmarshal | 6390816 | 190 ns/op | 53 | 96 |
ColferMarshal | 10938900 | 108 ns/op | 51 | 64 |
ColferUnmarshal | 7260112 | 166 ns/op | 52 | 112 |
为了提高序列化的效率，根据实验结果采用 protobuf+colfer 的混合序列化方式，当需要序列化操作时，调用 protobuf 的序列化方式，当将数据进行序列化时则采用 colfer 方式加快序列化的效率，这比单独使用 protobuf 序列化提高了 40% 的性能，表 2 是 gogoprotobuf 和混合序列化在相同测试环境(Intel Core i7 CPU@1.8GHz × 4 、内存 8G、Go1.14 linux/amd64)下的性能对比。
表2 gogoprotobuf和混合序列化性能对比
benchmark | iter | time/iter | bytes/op | allocs/op |
GogoprotobufMarshal | 9799002 | 121 ns/op | 32 | 1 |
GogoprotobufUnmarshal | 6607788 | 182 ns/op | 120 | 2 |
混合序列化Marshal | 16514504 | 69.6 ns/op | 32 | 1 |
混合序列化Unmarshal | 10472240 | 103 ns/op | 85 | 2 |
Raft Log 分离与定制存储
在 etcd-raft 模块中，Raft Group 中的 Leader 节点接收客户端发来的 Request，将 Request 封装成 Raft Entry(Raft Log 的基本组成单元)追加到本地，并通过 gRPC 将 Raft Entry 发送给 Raft Group 中其他 Follower 节点，当 Follower 节点收到 Raft Entry 后进行追加、刷盘以及回复处理结果的同时，Leader 将本地 Raft Entry 进行刷盘，两者同步进行。等 Leader 节点收到过半数节点的肯定回复后，提交 Raft Entry 并将其应用到状态机(将 Raft Entry 中包含的业务数据进行持久化)，然后将处理结果返回客户端。
从上面的分析中可以看出 Raft Log 在副本之间达成共识、节点重启以及节点故障恢复等环节都起到至关重要的作用，Raft Log 与业务数据共同存储在同一个 RocksDB 中，在查询高峰期必然会发生磁盘 I/O 资源争抢，增加查询等待时延，降低数据库的整体性能。在 TPCC 场景下进行了 Raft Log 与业务数据写入量的测试，测试场景如下：在物理机(CPU：6240，72 核， 内存:384G，系统硬盘：480G，数据盘：375G+SSD，硬盘:2T*7)上启动单节点 ZNBase 服务，系统稳定后 init 6000 仓 TPCC 数据，观察整个过程中业务数据与 Raft Log 写入量的大小，测试结果如表 3 所示。
表3 TPCC 初始化过程数据量统计
TPCC仓数 | 业务数据量 | Raft Log数据量 | Raft Log写入量 |
6000 | 458GiB | 11GiB | 1.7TiB |
同时开展了 TPCC 场景下针对 Raft Log 各项操作数量的测试，测试场景如下：启动 3 个节点的 ZNBase 集群，系统稳定后 init 40 仓 TPCC 数据，观察网关节点在整个初始化过程中 Raft Log 各项操作数量的变化，测试结果如表 4 所示。将 RaftEntryCache 的大小从 16MiB 增加到 1GiB 后，相同场景下 Term 与 Entry 的查询数量下降到 0。
表4 TPCC 初始化过程Raft Log各项操作统计
插入 | 删除 | 查询RaftLogSize | 查询LastIndex | 查询Term | 查询Entry |
6.616M | 6.423M | 160K | 0 | 1.264K | 27 |
根据上述测试以及测试结果，可将 ZNBase 中 Raft Log 的操作特点总结如下：
在正常运行过程中，插入和删除操作是最多的且数量也很接近，说明 Raft Log 持久化的时间很短。查询 RaftLogSize 也是较为常规操作，其他操作都是在特殊场景下触发的，几乎可以忽略不计。
查询 Term 与查询 Entry 的操作次数取决于 RaftEntryCache 的大小，是由 ZNBase 内部实现机制决定的，Entry和Term的查询一般先去Unstable中查找，查找不到再去RaftEntryCache中查找，还是查找不到就到底层存储中查找。通常情况下RaftEntryCache大小设置合理的话可以命中所有查找。
ZNBase 实际运行过程中产生的 Raft Log 比真正持久化的业务数据多很多(5~10倍)，而且只要数据库持续运行(即使没有任何用户查询)就会源源不断的产生 Raft Log。Raft Log 是用户数据的载体，为了保证数据完整性和一致性 Raft Log 必须持久化。
ZNBase 中存储 raft Log 的引擎面临的真正挑战是频繁写入、删除以及短暂的存储给系统带来的性能损耗。
通过对 ZNBase 中 Raft Log 操作场景的详细分析，总结 Raft Log 存储引擎应该满足如下特征：
尽可能将待查询数据保存在内存中，减少不必要磁盘I/O;
写入的数据能够及时落盘，保证故障恢复后数据的完整性和一致性；
能够及时的清理被删除数据或是延迟清理被删除数据，减少不必要的资源占用。
针对这个问题，业内分别有不同的解决方案。以 TiDB 为例，目前 TiDB 的解决方案是：每个 TiKV 实例中有两个 RocksDB 实例，一个用于存储 Raft 日志(通常被称为 raftdb)，另一个用于存储用户数据以及 MVCC 信息(通常被称为 kvdb)。同时，TiDB 团队还开发了基于 RocksDB 的高性能单机 Key-Value 存储引擎 —— Titan。
而在 ZNBase 中直接使用 RocksDB 来存储 Raft Log 是不合适的，不能很好地满足 Raft Log 的具体使用场景。RocksDB 内部采用 LSMTree 存储数据，在 Raft Log 频繁写入快速删除并且还会持续进行随机查询的场景下，造成严重读放大和写放大，不能够充分发挥出 RocksDB 的优势，也对系统整体性能造成不利影响。
ZNBase 研发团队在详细调研分析 LevelDB、RocksDB、Titan、BadgerDB、FlashKey 以及 Aerospike 的具体架构与特征后，决定在 BadgerDB v2.0 的基础上进行定制优化，作为ZNBase 中 Raft Log 的专用存储引擎。Raft Log 定制存储实现了以下基本功能：
Raft Log 的批量写入与持久化；
Raft Log 的顺序删除与延迟 GC；
Raft Log 的迭代查询，包括：RaftLogSize 查询、Term 查询、LastIndex 查询以及 Entry 查询；
相关 Metrics 的可视化；
多引擎场景下的用户数据完整与一致保证策略。
ZNBase 中 Raft Log 定制存储整体部署架构如图 5 所示：
图 5：Raft Log 定制存储整体部署架构
部署时 BadgerDB 需要与 RocksDB 并列进行部署，即一个 Node 上部署相等数量的 RocksDB 实例和 BadgerDB 实例(由目前 ZNBase 中副本平衡策略所决定)。
查询请求的大致处理流程是先将 Raft Log 写入 BadgerDB，等待集群过半数节点达成共识后，再将 Raft Log 应用到状态机，即将 Raft Log 转化成用户数据写入到 RocksDB，用户写入成功后再将 BadgerDB 中已应用的 Raft Log 删除，同时将状态数据更新到 RocksDB 中。
ZNBase 中 Raft Log 定制存储的写、读流程如图 6 所示：
图 6：RaftLog 定制存储写、读流程
由于Raft Log 定制存储采用 Key-Value 分离的策略，完整的 Key-Value 数据首先写入 VLog 并落盘(如果是删除操作则在落盘成功后由 IfDiscardStats 更新内存中维护各 VLog File 的删除数据的统计信息，这些统计信息也会定期落盘，避免了 BadgerDB 中 SSTable 压缩不及时导致统计信息滞后的问题)，然后将 Key 以及元数据信息写入 Memtable(skiplist)。将 Level 0 SSTable 放入内存，同时将需要频繁查询的信息(RaftLogSize、Term 等)记录到元数据放入内存，加快随机读取的效率，减少不必要的 I/O。
已删除 Key 的清理依赖 SSTable 的压缩，对应 Value 的清理则需要 ZNBase 周期性调用接口，首先根据访问 IfDiscardStats 在内存中维护的 VLog file 的 discardStats，对备选文件进行排序，顺序遍历进行采样，若可以进行 GC 则遍历 VLog File 中的 Entry，同时到 Mentable (或 SSTable)查看最新元数据信息确定是否需要进行重写，需要重写则写入新的 VLog File，不需要则直接跳过，Raft Log 定制存储中 GC 处理流程如图 7 所示：
图 7 RaftLog 定制存储 VLog GC 流程
在将 Raft Log 进行独立储存后，必须要考虑多个存储引擎数据保持一致性的策略。Raft Log 存在的目的是为了保证业务数据的完整，因此在 Raft Log 与业务数据分开存储后不追求两者完全一致，而是 Raft Log 保持一定 的“冗余”。具体策略是每个 range 上的 Raft log 在被应用到状态机之后不会立刻被删除，会保留一段时间(例如：默认每个 range 默认保留 50 个 Raft Entry)，进而满足用户数据完整性的各项要求。同时，如果发现所需要的 Raft Log 在本地存储中找不到，则发送消息给 Leader 去请求，通过 MsgApp 或是 Snapshot 获取所需的 Raft Log。
ZNBase 研发团队完成上述优化后，开展了“迭代查询性能对比测试”与“TPCC 场景性能测试”。在“迭代查询性能对比测试”中，测试场景如下：启动单机单节点 ZNBase 服务，系统稳定运行后 init 40 仓 TPCC 数据，记录迭代器查询 RaftLogSize 与 Term 的总耗时。Raft Log 分别存储在 RocksDB、BadgerDB 以及 Raft Log 定制存储中，其中 ValueThreshold 设置为1KB，其他设置均采用默认值。
表5 迭代查询测试结果汇总
指标 | RocksDB存储Raft Log | BadgerDB存储Raft Log | 定制存储Raft Log |
迭代查询总延迟 | 463.6ms | 549.9ms | 48.5ms |
RocksDB读放大 | 约10 | — | 约7 |
从上述测试结果来看，在对 Badger 迭代器进行优化后，针对元数据的迭代查询速率得到大幅提升，相比 RocksDB 迭代查询延迟降低了约 90%。
在“TPCC场景性能测试”中，测试场景如下：在物理机(CPU：6240 72核 内存:384G 系统硬盘：480G 数据盘：375G+SSD硬盘:2T*7)启动单节点 ZNBase 服务，系统稳定后 init 6000 仓 TPCC 数据，观察整个过程中相应监控指标。
表6 TPCC 压测监控数据汇总表
指标 | RocksDB存储Raftlog | 定制存储Raftlog | 定制存储Raftlog(暂停GC) | ||
Init | Raft命令提交延迟 | 305ns | 275ns | ___ | |
RocksDB读放大 | 103 | 35 | ___ | ||
无负载 | Raft命令提交延迟 | 360ns | 280ns | ___ | |
压测 | Raft日志提交延迟 | 50ms | 15ms | 15ms | |
Raft命令提交延迟 | 240ns | 180ns | 180ns | ||
RocksDB读放大 | 10 | 7 | 6 | ||
从上述测试结果来看，Raft Log 采用定制存储后，raft Log 提交延迟下降约 60%，raft Log 应用延迟下降约 25%，RocksDB 读放大下降约 60%(高负载)，同时没有明显增加资源消耗。
综上，利用键值分离的思想优化 LSM 树，借助索引模块提升迭代查询性能，使用统计前置的策略提升系统 GC 的效率，能够很好满足 ZNBase 中 Raft Log 在各种操作场景下的性能要求。
Raft 心跳与数据分离
在 etcd-raft 模块的实现逻辑中，负责处理节点间心跳请求以及负责处理用户、系统请求的Processor 共享同一个资源池，由于储存消息请求的队列采用 FIFO 执行方式，这样就可能会导致所有的资源被用户、系统请求占用从而导致节点间心跳请求被延迟等待处理，过长的延迟处理时间可能会导致集群之间由于无法及时响应心跳请求出现节点失效情况的发生。
因此，为了保证集群的稳定性，在此将 Raft Processor 的处理逻辑进行分离，负责处理节点间心跳请求的 Processor 将被分配一定份额的资源，这一部分资源只用于 Processor 处理节点间心跳消息。
分离 Raft Scheduler 为 Tick、ReadyRequest(Ready 与 Request )两类，两类 Scheduler 各自拥有自己的资源池(Gouroutine)以及 RangeID 消息队列，同时对 Raft Scheduler 处理消息流程进行分离，将处理 tick 请求的流程从之前的总流程中拆分，从而有效降低 Raft 心跳延迟，测试结果显示优化后 Tick 处理的平均延迟下降 30%，具体如下图所示：
Tick 处理的平均延迟(优化前)
Tick 处理的平均延迟(优化后)
总结
本系列文章介绍了 Raft 一致性算法在分布式 NewSQL 数据库 ZNBase 中发挥的重要作用，以及 ZNBase 项目团队根据自身业务特性与需求，在落地 Raft 一致性协议的过程中对其做出的五大优化改造，希望能对开发者进一步学习 Raft 一致性协议在分布式数据库场景下的实践过程有所帮助。
关于 ZNBase 的更多详情可以查看：
官方代码仓库：https://gitee.com/ZNBase/zn-kvs
ZNBase 官网：http://www.znbase.com/
对相关技术或产品有任何问题欢迎提 issue 或在社区中留言讨论。同时欢迎更多对分布式数据库感兴趣的开发者加入我们的团队！
全文完。