如何避免单节点故障
通过数据复制方案,可以提高服务可用性,避免单点故障;提升读吞吐量、降低访问延迟。
多副本复制是如何实现:
- 主从复制:全同步复制、异步复制、半同步复制
- 全同步复制:指主收到一个写请求后,必须等全部从节点确认返回后,才能返回给客户端成功。如果一个节点故障,整个系统就会不可用。
- 这种方案保证了副本的一致性,牺牲了可用性。
- 异步复制:指主收到一个写请求后,可及时返回给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阻塞。
