浅谈Raft协议

What is Raft?
Raft is a consensus algorithm that is designed to be easy to understand. It’s equivalent to Paxos in fault-tolerance and performance. The difference is that it’s decomposed into relatively independent subproblems, and it cleanly addresses all major pieces needed for practical systems. We hope Raft will make consensus available to a wider audience, and that this wider audience will be able to develop a variety of higher quality consensus-based systems than are available today.

以上描述出自Raft官网：https://raft.github.io/，大致意思就是作为分布式场景下的共识算法，Raft与Paxos性能差不多，但是Raft更容易理解，相比Paxos更容易使用。

1、Raft作用
在传统的单机架构的系统中，如果客户端（client）向服务端请求修改一个数据是非常容易的，直接修改即可，无需考虑其它问题。但是在分布式架构中，同样一个修改操作，就可能会变得很复杂。举个例子，比如一个web系统，服务端部署了3台机器（server1、server2、server3），用户通过页面想要将某个数据value的值由1改成2，client请求通过负载均衡算法会落到其中一台服务器server1，那么server1.vaule=2，但是其它两台机器上的还是1，这时如果client有读请求落到其它两台机器，那么读取到的值就不对了；又或者同时有多个client同时对value值进行修改等等，最终都可能会导致server1、server2、server3上的value值不一致，这个问题该如何解决？Raft协议就可以很好的解决以上数据不一致的问题，那么下面就讲下Raft是如何保证数据一致的。

2、节点角色
实现Raft算法的分布式节点有3个角色，或者说3个状态：leader、follower、candidate。

• follower
  （1）服务启动后，节点初始状态都是follower，每个follower初始都会分配一个随机的选举超时时间（election timeout），一般在150ms-300ms之间，时间到了就会转换成candidate状态；
  （2）如果接收到leader的心跳信息，就会重置选举超时时间，只要leader的心跳不断，它就一直是follower（为了防止篡权）
  （3）follower能够响应leader和candidate的请求，收到candidate请求时如果自身还没有进行过投票（即选举超时时间还没到），会给candidate投一票，并且重置自己的选举超时时间；

• candidate
  该状态的节点会进行投票选举，选举过程如下：
  （1）节点由follower变成candidate后，首先会给选举任期加1，同时给自己投一票；
  （2）向其它节点发送投票请求，准确地说应该是向其它节点拉票，让其它节点投自己；
  （3）接受到其它节点的响应后，给自己的票数加1，如果自己的票数超过半数节点数，那么就会成为leader；
  （4）如果接收到leader节点的信息，就会变成follower；

• leader
  （1）leader只能由candidate节点转变而来；
  （2）成为leader后，就会周期性（heartbeat timeout）地向其它节点发送心跳信息，然后重置自己的election timeout；其它节点收到心跳后会重置它们的选举超时时间，成follower，心跳的作用主要就是为了防止其它节点篡权;
  （3）如果leader节点长时间没有发送心跳，或者其它节点长时间没有收到leader的心跳，那么就会重新进行选举，leader就会变成follower。

有一张图用来表示以上状态直接的流转，这张图摘抄自官网Raft paper

注：上面描述中涉及到了两个超时时间：election timeout和heartbeat timeout，heartbeat timeout必须要小于election timeout，否则其它节点肯定就会篡权。

3、Raft两个核心阶段
3.1 领导选举
在前面讲解各个节点角色的时候，已经对领导选举的过程做了介绍了，这里做一个总结：
（1）节点启动后默认是follower，每个follower都有一个随机的选举超时时间（150ms-300ms）；
（2）某个follower节点率先到达超时时间后，变成candidate，开始向其它节点进行拉拉票，拉票前先给自己投一票；
（3）其它节点收到candidate节点发来的消息后，会将自己的term和candidate的term进行比较，如果自己的term更大，就投给自己，否则投给canditate，并且重置自己的election timeout；candidate每收到一个响应就会给自己的票数加1，如果票数超过总节点数的半数，就会成为leader；
（4）leader节点为了维护自己的领导地位，会定时发送心跳（该心跳有个专业术语叫AppendEntries messages）给其它节点，其它节点接受到心跳后会重置自己的选举超时时间，并将状态转成follower；
（5）如果leader节点挂了，或者follower节点 长时间没有收到心跳，就会重新进行选举，重复上面4个步骤。

用一组图来表示领导选举过程如下：

3.2 日志复制
日志复制是Raft协议保证数据一致的另一个非常重要的手段，领导选举完成后，整个集群就有了一个leader节点，其余都是follower节点，如果此时客户端有变更请求过来，只能通过leader节点进行更新，再由leader节点将更新复制到其它节点，这个信息时通过心跳来同步给其它节点的。具体的工作过程如下：
（1）客户端发送一个请求set a = 5，leader节点收到这个请求后先将a=5写入到本地log（追加的方式写入），此时还没有最终提交到内存或者磁盘（此处说的磁盘比如最终持久化到数据库，跟本地log不是一回事）
（2）然后在下一个心跳上将更改发送给其它所有follower，follower收到更改后，也是先写入到各自的本地log，然后就会响应leader—— 一阶段提交；
（3）leader节点收到超过半数节点的响应后，才提交到自身节点上，提交完成之后就会回复client成功，然后再下次心跳会同步给其它follower节点，其它节点收到心跳后再各自提交到到各自节点，此时集群数据就已经一致了—— 二阶段提交。

用一组图来表示日志复制的过程如下：

4、Snapshot
集群中每一个节点，都在本地维护着一个快照，里面记录了最后提交的index、当前选举的任期term和数据的最新值，这样在发生故障的时候，就会通过读取快照从而快速恢复到之前的状态。

以上就是Raft算法的简单介绍，只是简单讲解了Raft算法的工作过程，并没有针对各种问题展开分析，其实像leader挂了，集群就会重新选举，选举过程上面已经介绍了；像脑裂问题，Raft算法的设计上就已经解决了脑裂问题：只要收到超过半数以上的选票时才会成为leader，这中机制已经保证了不会出现脑裂问题。