raft算法详解

一、raft算法的背景

1.什么是raft算法

一致性算法是分布式系统的基石。在所有一致性算法中，Paxos 算法由莱斯利·兰伯特（Leslie Lamport）于 1990 年提出，是一种基于消息传递的一致性算法，被认为是类似算法中最有效的。

Paxos 算法虽然很有效，但原理较为复杂，截止目前，实现 Paxos 算法的开源软件很少，比较出名的有 Chubby、LibPaxos。此外，Zookeeper 采用的 ZAB（Zookeeper Atomic Broadcast）协议也是基于 Paxos 算法实现的，不过 ZAB 对 Paxos 进行了很多改进与优化，两者的设计目标也存在差异——ZAB 协议主要用于构建一个高可用的分布式数据主备系统，而 Paxos 算法则是用于构建一个分布式的一致性状态机系统。

由于 Paxos 算法过于复杂、实现困难，极大地制约了其应用，而分布式系统领域又亟需一种高效而易于实现的分布式一致性算法，在此背景下，Raft 算法应运而生。

Raft 算法在斯坦福 Diego Ongaro 和 John Ousterhout 于 2013 年发表的《In Search of an Understandable Consensus Algorithm》中提出。相较于 Paxos，Raft 通过逻辑分离使其更容易理解和实现，目前，已经有十多种语言的 Raft 算法实现框架，较为出名的有 etcd、Consul 。

1.2Paxos 算法的缺点

Paxos 算法的一些术语难以理解，需要很多专门的文档去解释

Paxos 算法没有为构建实际的组件提供一个良好的基础

二、raft算法的基础

1.raft角色

一个 Raft 集群包含若干节点，Raft 把这些节点分为三种状态：Leader、 Follower、Candidate，每种状态负责的任务也是不一样的。正常情况下，集群中的节点只存在 Leader 与 Follower 两种状态。

• Leader（领导者） ：负责日志的同步管理，处理来自客户端的请求，与Follower保持heartBeat（心跳）的联系；

• Follower（追随者） ：响应 Leader 的日志同步请求，响应Candidate的投票请求，以及把客户端请求到Follower的事务转发（重定向）给Leader；

• Candidate（候选者） ：负责选举投票，集群刚启动或者Leader宕机时，状态为Follower的节点将转为Candidate并发起选举，选举胜出（获得超过半数节点的投票）后，从Candidate转为Leader状态。

上面是三个角色之间的转换关系,大概如下:

Follower—> Candidate : 时间片用完,进入选举

Candidate—>Leader : 获得集群过半的投票

Candidate—>Follower : 发现集群里面已经有Leader了(因为集群在选举出Leader之后,Leader会向集群群发消息),或者进入新的任期

Leader—>Follower : 发现具有更高任期(term)的服务器,辞去领导者的职务

2.Term

Raft 算法将时间划分成为任意不同长度的任期（term）。任期用连续的数字进行表示。每一个任期的开始都是一次选举（election），一个或多个候选人会试图成为领导人。如果一个候选人赢得了选举，它就会在该任期的剩余时间担任领导者,管理集群。在某些情况下，选票会被瓜分，有可能没有选出领导人，那么，将会开始另一个任期，并且立刻开始下一次选举。Raft 算法保证在给定的一个任期最多只有一个领导人(选举安全特性)。

注意:在任期(term)之间的空隙可能是不同时间被不同服务器观察的时间( The transitions between terms may be observed at different times on different servers.)

3.RPC

Raft 算法中服务器节点之间通信使用远程过程调用（RPC），并且基本的一致性算法只需要两种类型的 RPC，为了在服务器之间传输快照增加了第三种 RPC。

RPC有三种：

1. RequestVote RPC：候选人(Candidate)在选举期间发起。

2. AppendEntries RPC：领导人(Leader)发起的一种心跳机制，用于复制日志到追随者(Follower)

3. InstallSnapshot RPC: 领导者使用该RPC来发送快照给太落后的追随者(Follower)

4.raft 三个子问题

通常，Raft 集群中只有一个 Leader，其它节点都是 Follower。Follower 都是被动的，不会发送任何请求，只是简单地响应来自 Leader 或者 Candidate 的请求。Leader 负责处理所有的客户端请求（如果一个客户端和 Follower 联系，那么 Follower 会把请求重定向给 Leader）。

为简化逻辑和实现，Raft 将一致性问题分解成了三个相对独立的子问题。

• 选举（Leader Election） ：当 Leader 宕机或者集群初创时，一个新的 Leader 需要被选举出来；

• 日志复制（Log Replication） ：Leader 接收来自客户端的请求并将其以日志条目的形式复制到集群中的其它节点，并且强制要求其它节点的日志和自己保持一致；

• 安全性（Safety） ：如果有任何的服务器节点已经应用了一个确定索引(index)的日志条目(entry)到它的状态机中，那么其它服务器节点不能在该索引位置应用一个不同的指令。

5.raft 五个特性

特性	解释
选举安全特性（Election Safety）	对于一个给定的任期号(term)，至多有一个领导者(Leader)被选举出来
领导者只增加原则（Leader Append-Only）	领导者节点绝对不会删除或者覆盖自己的日志，只会增加日志信息
日志匹配原则（Log Matching）	如果两个日志(log)都有一个索引(index)和任期(term)都相同的日志条目(entry)，那么我们就认为这个日志从头开始到这个索引位置之间的全部日志条目都是相同的
领导人完全特性（Leader Completeness）	如果某个日志条目在某个任期号中已经被提交&#x