Raft协议学习笔记

目录

 

1. 前言

常见的一致性协议主要有：PaxOS、Raft、ZAB、PacificA等。同PaxOS，Raft也不考虑拜占庭将军问题（Byzantine failures，注：比特币采用工作量证明PoW和股权证明PoS解决了拜占庭将军问题）。

2. 名词

Distributed Consensus	分布式一致性
Distributed Consensus Algorithms	分布式一致性算法，PaxOS是分布式一致性算法的鼻祖，绝大多数的实现要么基于PaxOS，要么受PaxOS影响（如Zookeeper）。
	就分布式系统中的某个值（在PaxOS中叫决议，即Proposer）达成一致的算法。PaxOS是分布式一致性协议的鼻祖，在Google的三大件未推出之前少为人知，1989年提出。Leslie Lamport是大神的英文名，出生于1941年2月7日纽约。兰伯特目前就职于，他也是排版系统LaTeX的作者，2008年获得冯诺依曼奖，2013年获得图灵奖，麻省理工学院学士和布兰戴斯大学博士。最早的实现为Google内部使用的Chubby。
Raft	木筏协议，一种共识算法，旨在替代PaxOS，相比容易理解许多。斯坦福大学的两个博士Diego Ongaro和John Ousterhout两个人以易懂为目标设计的一致性算法，2013以论文方式发布。由于易懂，不从论文发布到不到两年的时间，即出现大量的Raft开源实现。为简化PaxOS的晦涩，它采用分而治之的办法，将算法分为三个子问题：选举（Leader Election）、日志复制（Log Replication）、安全性（Safety）和集群成员动态变更（Cluster Membership Changes）。
ZAB	Zookeeper采用的一致性算法，全称“ZooKeeper Atomic Broadcast”，即Zookeeper原子广播协议，实为Zookeeper版本的PaxOS。
	微软2008年提出的日志复制协议，与PaxOS和Raft不同，PacificA并不提供Leader选举，因此需要结合PaxOS或Raft，分布式消息队列Kafka的ISR算法类似于PacificA。小米开源的KV系统基于PacificA实现。
Viewstamped Replication	简称VR，最初被提出是作为数据库中的一部分工作，2012年作为单独的分布式共识算法再次发表。
Log Replication	日志复制
Leader Election	领导选举
Log	代表一个修改操作
Entry	（日志）条目（代表一个修改操作），Log在Raft中的实体，即一个Entry表示一条Log
Term	任期（可简单理解成租约，但稍有不同），是一个从0开始递增的整数值，每次发起选举时增一，最终所有节点的Term值是相同的。等同于ZAB协议中的zxid的高32位，即ZAB中的Epoch。
Index	和Term密切相关，Term针对的是选举，而Index针对的是一条Log，它的值也是从0开始递增。同样最终所有节点的Index也相同，如果两个节点的Term和Index均相同，则这两个节点的数据是完全一致的。等同于ZAB协议中的zxid的低32位。
Node	节点
Single Node	单节点
Multiple Nodes	多节点
Leader	领导（唯一接受修改操作的）
Follower	跟随者（投票参与者）
Candidate	候选人（唯一具有发起选举的）
Vote	投票
Heal	恢复，比如恢复网络分区（Heal the network partition）
Step Down	下台，当一个Leader发现有更大的Term时，自动降为Follower
Logic Clock	逻辑时钟，由Lampert提出，原因是分布式中无法使用精准的时钟维护事件的先后顺序，方法是为每个消息（或日志）加上一个逻辑时间戳。在ZAB协议中，每个消息均由唯一的zxid标识。zxid是一个64位无符号整数值，被分成两部分：高32位是Epoch，低32位是一个从0开始的递增值。类似于Raft的Term，每次选举新Leader，Epoch值增一，但同时zxid值清0。而Raft也类似，实际也是两部分组成，Term对应于Epoch，Index对应于zxid的低32位。
Quorum	法定人数
Brain Split	脑裂，同一个网络的节点被分成了两个或多个不互通的部分

3. 什么是分布式一致性？

多个节点（Multiple Nodes）的数据完全相同，即为分布式一致性。但因为多个节点通过网络互联，并不一定时刻可用，而服务不能因为某些节点（特别是少数节点）不可用时，导致整个系统不可用。

Raft将节点分成三种角色：Leader、Follower和Candidate，一个节点可为三种角色中的任意一种，但同一时刻只会为其中一种角色。正常情况下，只有Leader和Follower两种角色的节点，只有在选举时才会出现Candidate角色节点，而且可能多个节点同时处于Candidate角色同时竞争选举。

4. Raft选举

4.1. 什么是Leader选举？

Raft协议中，一个节点有三个状态：Leader、Follower和Candidate，但同一时刻只能处于其中一种状态。Raft选举实际是指选举Leader，选举是由候选者（Candidate）主动发起，而不是由其它第三者。

并且约束只有Leader才能接受写和读请求，只有Candidate才能发起选举。如果一个Follower和它的Leader失联（失联时长超过一个Term），则它自动转为Candidate，并发起选举。

发起选举的目的是Candidate请求（Request）其它所有节点投票给自己，如果Candidate获得多数节点（a majority of nodes）的投票（Votes），则自动成为Leader，这个过程即叫Leader选举。

在Raft协议中，正常情况下Leader会周期性（不能大于Term）的向所有节点发送AppendEntries RPC，以维持它的Leader地位。

相应的，如果一个Follower在一个Term内没有接收到Leader发来的AppendEntries RPC，则它在延迟随机时间（150ms~300ms）后，即向所有其它节点发起选举。

采取随机时间的目的是避免多个Followers同时发起选举，而同时发起选举容易导致所有Candidates都未能获得多数Followers的投票（脑裂，比如各获得了一半的投票，谁也不占多数，导致选举无效需重选），因而延迟随机时间可以提高一次选举的成功性。

4.2. 选举的实现

在Raft中，和选举有关的超时值有两个：

选举超时（Election Timeout）	Follower等待成为Candidate的时间，为随机时间，随机范围为150ms~250ms。如果在超时之前收到了其它的AppendEntries，则重置选举超时重新计时，否则在选举超时后，Follower成为Candidate，投票给自己（Votes for itself）并发起新的选举任期（Term），发送RequestVote给所有其它节点，以请求投票给自己。如果在这个Term时间内仍然没有获得投票，则重置选举超时，以准备重新发起选举。而一旦获得多数节点的投票，则成为Leader。成为Leader后，定期性的发送AppendEntries给所有Followers，以维持Leader地位。发送AppendEntries的间隔叫作心跳超时。
心跳超时（Heartbeat Timeout）	Follower会应答每一个AppendEntries，一个选举任期（Election Term）会一直存在，直到有新的Follower成为Candidate。Leader节点通过定期发送AppendEntries维护自己的Leader地位，定期的间隔时长即为心跳超时时长。在Raft中，心跳方向是：Leader -> Follower。

 

如果一个Follower在一个Term时间内没有收到AppendEntries（并非要求是来自Leader的AppendEntries，其它Candidates也一样有效），则它成为Candidate，并在等待选举超时（Election Timeout）后发起选举。

要求获得多数节点的投票，可以保证每个任期（Term）内只有一个Leader。如果两个Candidates同时发起选举，则会分割投票，这样需要再重新发起选举。Raft设计“选举超时”，可以降低两个或多个Candidates同时发起选举的概率，减少连续重选举。

Redis的选举有个借鉴意义，在Redis集群中，不同节点可有不同权重，权重大的优先获得发起选举几率。在Redis中，权重是指复制节点数据的新旧程度，而对Raft来说可考虑机架机房等作为权重。

4.3. Term和Lease比较

Raft中的Term可以简单看成Lease（租约），但概念上仍然是有区别的。Lease通常是一个节点向一个中心化节点请求，而Term是无中心化的。

如果没有发生选举超时，则Term的值不会发生变化，否则至少增一。

4.4. 选举图示

每个节点的Term值初始化为1（圆圈中的数字），每个节点选举超时时间为一个150ms~300ms的随机值（实际实现可以调整，但这个值是发明者测试得到的优值，详情请参见两位斯坦福大学教授的论文）：

 

 

节点S2最先发起选举成为Leader，在发起选举之前，它需要先自增自己的Term值，因此Term值由1变成2，同时其它节点的Term值也需要更新为比自己大的Term值（如果一个Leader遇到一个更大的Term，它需要主动降为Follower）：

 

人工将节点S1和S2停掉，这时两者不可用。这会导致其它正常的节点S3、节点S4和节点S5在选举超时时间内收不到来自Leader的心跳（实为AppendEntry），因此会触发节点S3、节点S4和节点S5发起选举（究竟哪个节点发起选举，视哪个节点最先达到选举超时）：

因为节点S2的数据处于未提交状态，因为它的已提交Index值要小于S3和S5，它没有最新的数据，不可能成为新的Leader。新的Leader必然在S3和S5中产生。先强制重置S2的选举超时时长，以让出优先发起选举：

虽然S3和S5均有最新的数据，但因为S3的Term小于S5的Term，因此只有S5才能成为Leader，这样最新的Term值将为5+1为6：

这个时候恢复节点S1，Term值是否会改变？

一个Leader节点，如果遇到比自有更大的Term值，则主动放弃Leader身份，并使用原Term替代自己的Term，然后转变为Candidate重新开始选举。

非Leader节点也是一样的，只要遇到比自己大的Term，都会使用更大的Term替代自己的Term。这样能保证节点均能正常通信时，Leader节点总是持有最大的Term。

4.5. 选举总结

能成为Leader的条件：

1) 有最大的Term；

2) 如果Term相同，则有最大的Index；

3) 如果Term相同，Index也相同，就看谁最先发起；

4) 最先发起者也不一定成为Leader，还得看谁最先获得多数选票。

 

一个Leader主动放弃Leader条件：

1) 遇到比自己更大的Term，这个时候会转为Follower。

5. Raft日志复制

5.1. 什么是日志复制？

Leader收到一个修改请求后，先将该请求记录到本地日志，这条日志在Raft中叫作Enry，此时处于未提交状态（Uncommitted），然后复制Entry给所有的Followers。当多数Followers节点确认已完成该Entry的写入后，Leader本地提交该Entry，响应客户端成功，这个过程叫日志复制（Log Replication）。如果一个Entry不能复制到多数节点，则该Entry状态一直为未提交，如果发生Leader转换，有可能被覆盖。

5.2. 日志复制的实现

正常的复制不需要理解，主要看异常时的复制处理。让节点S5成为Leader，然后停掉节点S2、S3和S4，然后客户端再请求写操作，但此时由于写操作不能得到多数节点的确认，所以无法提交（不能应用到状态机中）：

先停掉节点S1和S5，再恢复节点S2、S3和S4，并让节点S3成为Leader，然后客户端发起一笔写操作。让写操作在三个节点S2、S3和S4中得到确认，这样该笔写操作为已提交状态（Committed），可以看到变成如下状态了。显然节点S1和节点S5上存在了两笔脏数据：

恢复节点S1：

停止节点S3，构造条件让S1成为新的Leader：

5.3. 脑裂时的复制

网络分裂时，出现两个Leader：

 

 

具有多数节点的一方仍然能够继续，但少数一方已不可用，这个时候从节点B读不到最新的数据：

 

 

当网络恢复后，节点B发现更大的Term，自动从Leader将为Follower，同时回滚未提交的Entries，集群又重新实现一致。

 

6. 概念对比

Raft	PaxOS （Multi PaxOS）	ZAB	PacificA	Viewstamped Replication
获得多数同意	获得多数同意	获得多数同意	需所有都同意	获得多数同意
强Leader（领导），总是包含了最全最新的日志，日志无空洞，随机化简化Leader选举（Redis也采用了这个方法，并且加了节点权重）。	Proposer（提议者），允许有多个Proposer，并且不一定最包含了最全最新的日志，日志可存在空洞	强Leader（领导）	Primary（主）	Primary
Follower（跟随者）	Acceptor（接受者）	Follower（跟随者,参与投票）	Secondary（副），接收Primary的心跳，一个Primary对多个Secondary	Backup
Candidate（候选者）	Learner（学习者）	Looking（竞选状态）
		Observing（观察者，不参与投票，只同步状态）
Entry	达到一致的叫Value（即决议），达到一致前叫提议	类似PaxOS
Term（任期）	Ballot（选票）	Epoch（纪元），为txid的高32位（注：Redis中也叫Epoch，作用类似）	View
Index（序号）	Proposal Number	txid的低32位	Serial Number

7. 共性探讨

所有的并不是完全孤立的，而是存在很多共性。

7.1. PacificA和HBase和Kafka

PacificA和HBase均依赖于PaxOS这样的设施，HBase依赖于Zookeeper，PacificA同样依赖于类似的配置管理服务。

如同HBase依赖Zookeeper来发现Keys的位置信息，PacificA依赖配置管理服务发现分片的位置。

Kafka其实也类似，早期Kafka直接将位置信息存储在了Zookeeper中，遭遇了Zookeeper吞吐瓶颈，于是采取和HBase类似的做法，将位置信息作为一个特殊的Partition。

7.2. Redis&Raft&ZAB&PaxOS

Redis同Raft、ZAB和PaxOS并不是一类东西，但核心均有Quorum的朴素思想，即服从多数（多数人理解的即为真理），而且均依赖于一个递增的值来达到一致性状态，这个递增的值在Redis和ZAB中叫Epoch，Raft中叫Term。

8. 总结浓缩

8.1. 三种角色

1) Leader（领导者）

2) Follower（跟随者）

3) Candidate（候选人）

8.2. 两种RPC

1) AppendEntry（心跳和写操作）

2) RequestVote（请求投票）

8.3. 两个超时时间

中文名	英文名	主要问题	小技巧
选举超时	Election Timeout	选票分裂造成活锁	随机时间（Redis非强一致，另加了权重）
心跳超时	Heartbeat Timeout	不能小于选举超时时长

9. 参考

1) 

2) 

3) 

4) 

5) 

6) 分布式共识(Consensus)：Viewstamped Replication、Raft以及Paxos

7)