Raft协议:etcd如何实现高可用、数据强一致

如何避免单节点故障

通过数据复制方案,可以提高服务可用性,避免单点故障;提升读吞吐量、降低访问延迟。

多副本复制是如何实现:

• 主从复制:全同步复制、异步复制、半同步复制
  • 全同步复制:指主收到一个写请求后,必须等全部从节点确认返回后,才能返回给客户端成功。如果一个节点故障,整个系统就会不可用。
  • 这种方案保证了副本的一致性,牺牲了可用性。
  • 异步复制:指主收到一个写请求后,可及时返回给client,异步将请求转发给每个副本,若还未将请求转发到副本前就故障了,则可能导致
  • 数据丢失,可用性高了
• 去中心化复制:在一个n副本节点集群中,任意节点都可以接受请求,但一个成功的写入需要w个节点确认,读取也必须查询至少r个节点。

共识算法拆分为三个自问题:

• Leader选举:Leader故障后集群能快速选出新Leader
• 日志复制:集群只有Leader能写入日志,Leader负责复制日志到Follower节点,并强制Follow节点与自己保持相同;
• 安全性:一个任期内只能产生一个Leader、已提交的日志条目在发生Leader选举时,一定会存在更高任期的新Leader日志中、各个节点的状态机应用
  • 的任意位置的日志条目内容应一样等。

Leader选举

在Raft状态中定义了集群中的节点状态,任何时刻,每个节点肯定处于其中一个状态:

• Follower,跟随者,同步从Leader收到的日志,etcd启动的时候默认为此状态;
• Candidate,竞选者,可以发起Leader选举;
• Leader,集群领导者,唯一性,拥有同步日志的特权,需定时广播心跳给Follower节点,以维持领导者身份。

Follower节点接收Leader节点心跳信息超时后,它会转变成Candidate节点,并可发起竞选Leader投票,若获得集群多数节点的支持,它就转换为Leader节点。

通过任期号,可以比较哥哥节点的数据新旧、识别过期的Leader等,它在Raft算法中充当逻辑时钟,发挥着重要作用。

etcd默认心跳间隔时间是100ms,默认竞选超时时间为1000ms,Raft为了优化选票被瓜分导致选举失败的问题,引入随机数,每个节点等待发起选举的时间点不一致,
优雅的解决了潜在的竞争活锁,同时易于理解。

如何避免无效的选举？

• 在etcd 3.4中,etcd引入了一个PreVote参数,可以用来启用PreCandidate状态解决此问题。
• Follower在转换成Candidate状态前,先进入PreCandiate状态,不自增任期号,发起预投票。
• 若获得集群多数节点认可,确定有概率成为Leader才能进入Candidate状态,发起选举流程。

日志复制

Leader是如何知道从那个索引位置发送日志条目给Follower,以及Follower已复制的日志最大索引是什么:

• Leader会维护两个字段来追踪各个Follower的进度信息,一个字段是NextIndex,表示Leader发送给Follower节点的下一个日志条目索引。
• 一个字段是MatchIndex,表示Follower节点已复制的最大日志条目的索引。

日志条目什么时候才会追到稳定的Raft日志中,Raft模块负责持久化吗？

• 上层应用通过Raft模块的输出接口,获取到待持久化的日志条目和待发送给Peer节点的信息后,需持久化日志条目到自定义的WAL模块,通过自定义的网络模块
  • 将消息发送给Peer节点。
• etcd Raft模块提供了一个内置的内存存储模块实现,Raft日志条目保存在内存中。etcd基于HTTP协议实现peer节点间的网络通信,并根据消息类型,支持选择
  • pipeline、stream等模式发送,显著提高了网络吞吐量、降低延时。

日志复制的过程:

• etcdserver 模块通过channel从Raft模块获取到Ready结构后,Leader结果通过基于HTTP协议的网络模块将追加日志条目消息广播给Follower,并同时将带持久化
  的日志条目持久化到WAL文件中,最后将日志条目追加到稳定的Raft日志存储中。
• 各个Follower收到追加条目消息,并通过安全检查后,它会持久化消息到WAL日志中,它持久化消息到WAL日志中,并将消息追加到Raft日志存储,随后会向Leader
  回复一个应答追加日志条目的消息,告知Leader当前已复制得到的日志最大索引。
• Leader收到应答追加日志条目消息后,会将Follower回复的已复制日志最大索引更新到跟踪Follower进展的MatchIndex字段。

安全性

选举规则

当节点收到选举投票的时候,需检查候选者的最后一条日志中的任期号,若小于自己则拒绝投票。如果任期相同,日志却比自己短,也拒绝为期投票。

Expensive Request是否影响写请求性能

• etcd 3.0线性读请求需要走一遍Raft协议持久化到WAL日志中。
• etcd 3.1引入ReadIndex机制提升读性能,读请求无需在持久化到WAL中。
• etcd 3.2 boltdb的事务锁有粗力度的互斥锁,优化为读写锁,读事务会增加读锁,写事物结束时要升级锁更新buffer,expensive request导致读锁长时间持有锁,最终导致请求超时。
• etcd 3.4 实现并发读,创建读事务的时候会全量拷贝buffer,读写事务不在因为buffer阻塞。