共计 4108 个字符，预计需要花费 11 分钟才能阅读完成。
Raft 简介
Raft 作为一种治理日志复制的分布式一致性算法，由斯坦福大学的 Diego Ongaro 和 John Ousterhout 在论文中提出。在 Raft 呈现之前，Paxos 始终是分布式一致性算法的规范。但 Paxos 绝对难以了解，Raft 的设计指标就是简化 Paxos，使得一致性算法更容易了解和实现。
Paxos 和 Raft 都是分布式一致性算法，其过程如同投票选举首领（Leader），参选者（Candidate）须要压服大多数投票者（Follower）给他投票，一旦选举出首领，就由首领发号施令。Paxos 和 Raft 的区别在于选举的具体过程不同，社区中对于 Raft 算法的具体解说十分丰盛，这里就不再赘述。查看详情
云溪数据库中的 Raft 算法
云溪数据库是分布式数据库，与 OceanBase、CockroachDB、TiDB 一样都是 NewSQL 家族的一员。云溪数据库具备强统一、高可用的分布式架构，可能程度扩大，提供企业级的平安个性，齐全兼容 PostgreSQL 协定，可能为用户提供残缺的分布式数据库解决方案。云溪数据库的整体架构如图 1 所示：
图 1：云溪数据库的整体架构
云溪数据库各方面的强一致性都通过 Raft 算法实现。首先，Raft 算法保障分布式多正本之间数据强一致性以及内部读写的一致性。简而言之，云溪数据库中数据会有多个正本，这些正本寄存在不同的机器上，当其中一台机器故障宕机后，数据库仍旧可能对外提供服务。此外，云溪数据库会依据插入数据的键，将数据划分为多个 Range，每个 Range 上的数据均由一个 Raft Group 来维持多个正本之间数据的一致性。因而，精确地说云溪数据库应用的是 Multi-Raft 算法。
具体来说，云溪数据库的存储层基于 RocksDB 开发，利用单机的 RocksDB，云溪数据库能够将数据疾速地存储在磁盘上；在呈现单机故障时，利用 Raft 算法能够疾速地将数据复制到机器上。在这个过程中，数据的写入是通过 Raft 算法接口实现的，而不是间接写入 RocksDB。通过 Raft 算法，云溪数据库变成了一个分布式的键值存储系统，面对不超过集群半数的机器故障状况宕机，齐全可能通过 Raft 算法主动把正本补全，做到业务对故障的无感知。
在我的项目开发后期，云溪数据库中的 Raft 算法采纳的是开源的 etcd-raft 模块，该模块次要提供如下几点性能：
· Leader 选举；
· 成员变更，能够细分为：减少节点、删除节点、Leader 转移等；
· 日志复制。
云溪数据库利用 etcd-raft 模块进行数据复制，每条数据操作都最终转化成一条 RaftLog，通过 RaftLog 复制性能，将数据操作安全可靠地同步到 Raft Group 中的每一个节点上。不过在实际操作中，依据 Raft 的协定，只须要同步复制到少数节点，即可平安地认为数据写入胜利。
然而在后续的生产实践中，云溪数据库研发团队逐步发现 etcd-raft 的模块仍存在诸多限度，于是陆续发展了如下多个方面的优化工作，具体包含：
· 新增 Raft 角色
· 新增 Leader 亲和选举
· 混合序列化
· Raft Log 拆散与定制存储
· Raft 心跳与数据拆散
上面将着重介绍第一点，即云溪数据库团队依据业务须要为 Raft 模块新增的三种角色。
云溪数据库对 Raft 模块的改良
新增 Raft 角色
1、强同步角色
为解决部署在跨地区的多数据中心数据同步问题，达到数据在多地独特写入的成果，实现地区级别的容灾能力，云溪数据库研发团队在 etcd-raft 模块中新增了强同步角色。
具体措施如下：
为正本减少强同步标识以及配置和勾销强同步标识的逻辑。
etcd-raft 模块原有的日志提交策略：Leader 失去超过半数正本（包含 Leader 本身）的投票能力提交 Raft 日志。云溪数据库在原有的过半数提交策略根底上，减少了强同步角色的日志提交策略——日志提交还须要失去所有强同步正本的投票。
为强同步角色设计了如图 2 所示的故障辨认与解决机制：通过心跳超时机制辨认强同步故障，提交日志时疏忽故障的强同步角色，并将故障信息录入数据库日志并告知用户。
为强同步角色的心跳超时 工夫减少热更新性能。
图 2 强同步角色的解决逻辑
通过以上四点革新后，etcd-raft 模块新加强同步角色，可能实现如下性能：
· 容许用户为指定正本配置或勾销强同步角色，不影响强同步角色所在正本的原有个性。例如对全能型正本配置强同步角色后，该正本仍然存储 Raft 日志和用户数据，参加投票，参加 Leader 选举，入选为 Leader 可提供读写服务，Follower 时可提供非一致性读。
· 强同步角色的数据与 leader 放弃同步。
· 容许用户配置强同步角色的心跳超时 工夫。如果强同步角色产生故障，Raft 集群将在该超时 工夫后复原写入性能，故障期间的写入也会在超时 工夫后提交。Raft 会在辨认到强同步角色故障后临时勾销强同步标记，并在该强同步角色故障解决后主动复原。强同步角色故障和复原的信息对用户可见。
· 容许用户在 SQL 终端查问强同步角色的配置状态。
2、只读型角色
因为云溪数据库具备 HTAP 的个性，因而须要在 Raft Group 中减少一种绝对独立的非凡正本，对外仅提供读服务（例如将该类型正本的存储引擎替换成列存引擎）以实现 OLAP 的性能。为了在 Raft Group 中减少这种非凡正本，同时不影响原有的集群个性，云溪数据库研发团队在 Raft 中设计了一种新的只读型角色。
具体实现措施如下：
- 减少只读型角色标识，减少只读型角色的创立、删除、重均衡逻辑。
- 减少只读型正本接管到申请后读取数据的逻辑：如果只读型角色的工夫戳不小于申请的工夫戳，则提供读服务；否则会重试屡次，重试达到限度后会将读取超时谬误返回到 SQL 终端。
- 为只读型正本的工夫戳更新距离、读取时的最大重试次数等参数减少热更新性能。
etcd-raft 模块新增只读型角色后，可能实现如下性能：
· 容许用户在指定地位创立、删除或挪动只读型角色。只读型角色反对基于负载平衡的重均衡性能，挪动到压力绝对较小的节点。
· 该角色对外仅提供读服务，存储 Raft 日志和用户数据，不参加投票，不参加 Leader 选举，可提供读服务。
· 容许用户配置只读型正本的工夫戳更新距离、读取时的最大重试次数，能够用于对只读型正本的读取性能进行调优。
· 容许用户在 SQL 终端查问只读型角色的配置状况。
3、日志型角色
云溪数据库不反对在两数据中心三正本部署模式下提供双活模式，无论如何部署正本的地位，总有一个数据中心领有过半数的正本。当领有过半数正本的数据中心故障时，另一个数据中心因为所领有的可用正本数不满足过半数，会导致云溪数据库无奈对外失常提供服务。为解决此类问题，进步云溪数据库的容灾能力，同时充分利用和整合资源，避免出现资源闲置造成的节约景象，晋升双活数据中心的服务能力，我的项目团队在 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 种新的角色，云溪数据库在跨地区集群容灾、反对 OLAP 等方面的能力失去了显著增强。
