ETCD背后的Raft一致性算法原理

项目中使用ETCD来实现服务发现和配置信息的存储,最近我抽空研究了一下ETCD和背后的一致性算法 — Raft算法的逻辑。

ETCD是什么

  • ETCD是一个go语言实现的高可靠的KV存储系统,支持HTTP协议的PUT/GET/DELETE操作;
  • 为了支持服务注册与发现,支持WATCH接口(通过http long poll实现);
  • 支持KEY持有TTL属性;
  • CAS(compare and swap)操作;
  • 支持多key的事务操作;
  • 支持目录操作

简单的来说,ETCD可以看做是一个no sql的存储,存的是key-value的node,每个node又可以像树形结构一样产生子node。它是集群化的运行状态来保证高可用,并且对外提供了一套简单友好的交互接口。

其实ETCD暂时就想介绍这么多,本文的重点在于Raft算法,只是我机智的考虑到站内的SEO才加上ETCD的名号:smirk:,以后会陆续写一些其他与ETCD相关的内容。

一致性的基础:Raft算法

ETCD实现高可靠的基础在于Raft算法,也是理解ETCD工作原理最重要的一部分。类似于zookeeper的zab协议(Paxos算法),Raft也是用于保证分布式环境下多节点数据的一致性,但更易于理解。

看了很多相关Raft算法的技术文章,要么是介绍的过于简单,要么是过于晦涩难懂。最后看了原始的论文In search of an Understandable Consensus Algorithm和infoQ上对应的中文翻译Raft 一致性算法论文译文才对整个逻辑有细致的理解。

首先来看看Raft大致的原理,这是一个选主(leader selection)思想的算法,集群总每个节点都有三种可能的角色:

  • leader
    对客户端通信的入口,对内数据同步的发起者,一个集群通常只有一个leader节点
  • follower:
    非leader的节点,被动的接受来自leader的数据请求
  • candidate:
    一种临时的角色,只存在于leader的选举阶段,某个节点想要变成leader,那么就发起投票请求,同时自己变成candidate。如果选举成功,则变为candidate,否则退回为follower

数据提交的过程

先看前两种角色,leader扮演的是分布式事务中的协调者,每次有数据更新的时候产生二阶段提交(two-phase commit)。在leader收到数据操作的请求,先不着急更新本地数据(数据是持久化在磁盘上的),而是生成对应的log,然后把生成log的请求广播给所有的follower。

每个follower在收到请求之后有两种选择:一种是听从leader的命令,也写入log,然后返回success回去;另一种情况,在某些条件不满足的情况下,follower认为不应该听从leader的命令,返回false。例如下图,leader收到客户端的写请求,我们暂时不考虑请求的具体值,虚线表示leader先写log,

leader写log

然后告诉所有的follower准备提交数据,先和我一样写log,

同步log

然后回到leader,此时如果超过半数的follower都成功写了log,那么leader开始第二阶段的提交:正式写入数据,然后同样广播给follower,follower也根据自身情况选择写入或者不写入并返回结果给leader。继续上面的例子,leader先写自己的数据,然后告诉follower也开始持久化数据,

leader持久化并同步数据

最终所有节点的数据达成一致,图中用实线表示已提交的数据。

数据一致

这两阶段中如果任意一个都有超过半数的follower返回false或者根本没有返回,那么这个分布式事务是不成功的。此时虽然不会有回滚的过程,但是由于数据不会真正在多数节点上提交,所以会在之后的过程中被覆盖掉。

选举的过程

上面只说了常规时候两种角色是如何协调工作的,还剩下candidate没说,对,就是一个follower是如何逆袭成为leader的。

初始状态下,大家都是平等的follower,那么follow谁呢,总要选个老大吧。大家都蠢蠢欲动,每个follower内部都维护了一个随机的timer。如下图,

每个follower都有timer

在timer时间到了的时候还没有人主动联系它的话,那它就要变成candidate,同时发出投票请求(RequestVote)给其他人。特殊情况如下图,S1和S3都变成了candidate,

转变为candidate

当然选不选就是人家的事了,原则是

每个follower一轮只能投一次票给一个candidate,

对于相同条件的candidate,follower们采取先来先投票的策略。如果超过半数的follower都认为他是合适做领导的,那么恭喜,新的leader产生了,如下图,S3变成了新一届的大哥,又可以很开心的像上一节一样的正常工作了。

所有follower接受candidate的大哥身份

但是如果很不幸,没有人愿意选这个悲剧的candidate,那它只有老老实实的变回小弟的状态。

选举完成之后,leader靠什么来确保小弟是跟着我的呢?答案是定时发送心跳检测(heart beat)。小弟们也是通过心跳来感知大哥的存在的。如下图

leader定期发心跳检测

同样的,如果在timer期间内没有收到大哥的联络,这时很可能大哥已经跪了,如下图,所有小弟又开始蠢蠢欲动,新的一轮(term)选举开始了。

新的一轮选举

好了,Raft算法的大致原理就是这样了,下面我们来说说一些没说到的细节问题。

选举时会产生的问题

之前说过,在选举阶段,每个follower如果在自身的timer到期之后都会变成candidate去参与选举。所以就这个candidate身份而言,是没有特别条件的,每个follower都有机会参选。但是,在分布式的环境里,每个follower节点存储的数据是不一样的,考虑一下下图的情况,在这些节点经历了一些损坏和恢复。此时S4想当leader,

不适合的candidate

但是如果S4成功当选的话,根据leader为上的原则,S4的log在index为4-7的数据,会覆盖掉S2和S3的8。如何解决这样的冲突的问题呢?有两种方法:第一种是S4在变为大哥之前,先向所有的小弟拿数据来保证自己数据是最全的;第二种方法是其他小弟遇到这样资历不足的大哥想上位的时候,完全不予以理睬。Raft算法认为第一种策略过于复杂,所以选择了第二种,保证数据只从leader流向follower。S4在vote请求中会带上自身数据的描述信息,包括:

  1. term,自身处于的选举周期
  2. lastLogIndex,log中最新的index值
  3. lastLogTerm,log中最近的index是在哪个term中产生的

S2和S3在收到vote请求时候会和自身的情况进行对比,每个节点保存的数据信息包括:

  1. currentTerm,节点处于的term号
  2. log[ ],自身的log集合
  3. commitIndex,log中最后一个被提交的index值

对比的原则有:

  1. 如果term < currentTerm,也就是说candidate的版本还没我新,返回 false
  2. 如果已经投票给别的candidate了(votedFor),则返回false
  3. log匹配,如果和自身的log匹配上了,则返回true

这个log匹配原则(Log Matching Property)具体是:

如果在不同日志中的两个条目有着相同的索引和任期号,则它们所存储的命令是相同的。

如果在不同日志中的两个条目有着相同的索引和任期号,则它们之间的所有条目都是完全一样的。

这样就可以一直等到含有最新数据的candidate被选上,从而保证领导人完全原则(Leader Completeness):

如果一个日志的index在一个给定term内被提交,那么这个index一定会出现在所有term号更大的领导人中。

好了,继续看图说话。S4的vote请求,

term lastLogIndex lastLogTerm
10 6 7

被无情的拒绝。接下来S3也变成了candidate,

S3变成candidate

一直等到S3变成了candidate,发出vote请求。

term lastLogIndex lastLogTerm
11 6 8

被S4和S10接受,变成新的leader,并初始化两个数组:

  1. nextIndex[ ],表示需要发给每个follower的下一个日志条目的索引(初始化为leader最新log的index+1,因为leader总是先假定所有的follower和自己是一致的,后面说明当有不一致的时候是如何协商的)
  2. matchIndex[ ],表示已经复制到每个follower的log的最高index值(从0开始递增)

在这个例子中,S3中的这两个数组会初始化为,

S1 S2 S4 S5
nextIndex 7 7 7 7
matchIndex 0 0 0 0

数据更新的问题

现在新的一届leader选举出来了,虽然选举的过程保证了leader的数据是最新的,但是follower中的数据还是可能存在不一致的情况。比如下图的S4,这就需要一个补偿机制来纠正这个问题。

在正常情况下,S3会给S4发心跳请求(一种名叫AppendEntries请求的特殊格式,entries为空),其中携带一些数据信息,包括,

term prevIndex prevTerm entries commitIndex
11 6 8 [ ] 6

commitIndex之前已经解释过了,是log中最后一个被提交的index值。prevIndex与lastLogIndex类似,都是最新的日志的index值,只是属于不同的请求类型。
prevTerm也与lastLogTerm类似,是prevLogIndex对应的term号。

S4在接收到该请求之后会做一致性的判断,规则包括,

  1. 如果 term < currentTerm返回 false
  2. 如果在prevLogIndex处的log的term号与prevLogTerm不匹配时,返回 false
  3. 如果一条已经存在的log与新的冲突(index相同但是term号不同),则删除已经存在的日志和它之后所有的日志,返回true
  4. 添加任何在已有的log中不存在的index,返回true
  5. 如果请求中leader的commitIndex > 自身的commitIndex,则比较leader的commitIndex和最新log index,将其中较小的赋给自身的commitIndex

结果与规则2不符合,返回false给S3。这时S3需要做一次退让,修改保存的nextIndex数组,将S4的nextIndex退化为6

S4的nextIndex退化为6

再次发送AppendEntries询问S4

term prevIndex prevTerm entries commitIndex
11 5 8 [ ] 5

如此循环的退让,一直到nextIndex减小到4

nextIndex减小到4

S3此时发送的请求为,

term prevIndex prevTerm entries commitIndex
11 3 3 [ ] 3

S4和自己的log匹配成功,返回true,并告诉leader,当前的matchIndex等于3。S3收到之后更新matchIndex数组,

S1 S2 S4 S5
nextIndex 7 7 4 7
matchIndex 0 6 3 0

并发送从nextIndex之后的数据(entries),

term prevIndex prevTerm entries commitIndex
11 3 3 [8] 4

S4再根据覆盖的原则,把自身的数据追平leader,并抛弃之后的数据。

S4的index4同步为leader的内容

这样消息往复,数据最终一致。

一些其他的问题

还有一些值得注意的特殊情况,比如log的清理。log是以追加的方式递增的,随着系统的不断运行,log会越来越大。Raft通过log的snapshot方式,可以定期压缩log为一个snapshot,并且清除之前的log。压缩的具体策略可以参考原论文。

还有集群节点的增减。当网络发生波动的时候,节点可能需要增减甚至发生网络分区。具体参考:ETCD系列之二:部署集群

总结

Raft是一种基于leader选举的算法,用于保证分布式数据的一致性。所有节点在三个角色(leader, follower和candidate)之中切换。选举阶段candidate向其他节点发送vote请求,但是只有包括所有最新数据的节点可以变为leader。

在数据同步阶段,leader通过一些标记(commitIndex,term,prevTerm,prevIndex等等)与follower不断协商最终达成一致。当有新的数据产生时,采用二阶段(twp-phase)提交,先更新log,等大多数节点都做完之后再正式提交数据。

以上的图片来自github上raft算法的算法动画的截图。

(完)

推荐阅读更多精彩内容