磐维数据库RAFT协议实现强一致性工作原理
磐维数据库RAFT协议实现强一致性工作原理
RAFT协议是一种用于实现分布式系统中一致性状态的算法，广泛应用于各种分布式数据库和存储系统中。本文将详细介绍磐维数据库高可用组件DCS中RAFT协议的实现原理，包括其工作流程、核心特性以及日志同步机制。
DCS工作流程
一个用户的请求发送过来，会经由HTTP Server转发给Store，以进行具体的事务处理。如果涉及到修改节点，则会给Raft模块进行状态变更、日志记录，再同步给别的DCS节点。
Raft协议的核心特性
DCS内部采用Raft 协议作为一致性算法，该算法使集群内各个节点的状态最终一致，并且允许局部失败。Raft 协议具备以下特性：
- 领导选举：通过投票选取主节点，一个新的集群启动时，或者老的 leader 故障时，会选举出一个新的 leader。
- 日志同步：leader 必须接受客户端的日志条目并且将他们同步到集群的所有机器。
- 安全性：如果leader节点已经应用了一个确定的日志条目到它的状态机中，那么其它follower节点不能在同一个日志索引位置应用一个不同的指令。
- 容错性：在2N+1个节点的集群中，最多容忍N个节点失败。
选举超时和心跳超时机制
Raft协议种存在两个超时设置用来控制选举过程：
- 选举超时（election timeout）：选举超时是追随者等待成为候选人的时间，这个等待时间控制在150ms到300ms之间，这个等待时间是随机的，随机是为了尽量避免产生多个candidate，给选主过程制造麻烦。
- 心跳超时（heartbeat timeout）：节点成为leader后，会根据心跳超时设置定时（默认为100ms）发送消息给他的Follower，Follower收到消息后会重置选举超时，这样就能阻止Follower成为candidate。
特殊情况处理
选举超时（election timeout）可以尽量避免产生多个candidate，但并不能100%保证不出现多个candidate的情况。当出现了多个节点成为candidate时，因每个candidate都无法获得过半票数，因此candidate节点将继续随机休眠，再次重试从Follower -> candidate -> leader的选举过程，直到产生Leader为止。
日志同步过程
由此Raft协议保障集群主机唯一，不会发生脑裂的情况。最后再进行日志同步：
当选举出Leader后，有Leader对外提供服务，并将变更内容通过与心跳相同的附加条目消息来完成同步。 客户端请求提交到 Leader，作为Entry（日志条目）写到本地，但因未同步至其他节点，Entry状态为未提交 Leader 将 Entry 跟随心跳信息发送到其它 Follower Leader 等待回应，直到大多数Follower节点写入条目 在领导节点上提交，并通知追随者该条目已提交 Leader 通过心跳通知 Followers Entry 已提交，Followers 收到通知后也会将 Entry 标记为提交状态 Raft 集群超过半数节点已经达到一致状态，可以确保强一致性。