分布式协议-Raft

一、分布式系统协议      

     分布式系统除了提升整个体统的性能外还有一个重要特征就是提高系统的可靠性。提供可靠性可以理解为系统中一台或多台的机器故障不会使系统不可用（或者丢失数据）。

     保证系统可靠性的关键就是多副本（即数据需要有备份），一旦有多副本，那么久面临多副本之间的一致性问题。一致性算法正是用于解决分布式环境下多副本之间数据一致性的问题的。

业界最著名的一致性算法就是大名鼎鼎的Paxos（Chubby的作者曾说过：世上只有一种一致性算法，就是Paxos）。但Paxos比较难懂，而Raft正是为了探索一种更易于理解的一致性算法而产生的。

     为什么有时候 Paxos 不是最佳选择呢？一是架构设计方面的原因，看参与复制的节点规模，规模太大就不适合采用 Paxos，同样也不适用其他的共识算法。二是工程实现方面的原因，在适用共识算法的场景下，

选择 Raft 还是 Paxos 呢？因为 Paxos 没有一个高质量的开源实现，而 Raft 则有 etcd 这个不错的工程实现，所以 Raft 得到了更广泛的使用。这里的深层原因还是 Paxos 算法本身过于复杂，直到现在，

实现 Raft 协议的开源项目也要比 Paoxs 更多、更稳定。    

 

二、Raft协议

   Raft是一种管理复制日志的一致性算法。如果要用一句话概括 Raft 算法，我觉得是这样的：从本质上说，Raft 算法是通过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致。

它的首要设计目的就是易于理解，所以在选主的冲突处理等方式上它都选择了非常简单明了的解决方案。

1.Raft将一致性拆分为几个关键元素：

• Leader选举：集群中必须存在一个leader节点。
• 日志复制：Leader节点负责接收客户端请求，并将请求操作序列化成日志同步。
• 安全性：包括leader选举限制、日志提交限制等一系列措施，来确保state machine safety。

除核心算法外还有集群成员变更、日志压缩等。

2.角色

Raft通过选举Leader并由Leader节点负责管理日志复制来实现多副本的一致性。

在Raft中，节点有三种角色：

• Leader：负责接收客户端的请求，将日志复制到其他节点并告知其他节点何时应用这些日志是安全的
• Candidate：用于选举Leader的一种角色
• Follower：负责响应来自Leader或者Candidate的请求

Leaders

• 一旦选举完成：发送心跳给所有节点；在空闲的周期内不断发送心跳保持Leader身份
• 如果收到客户端的请求，将日志追加到本地log，在日志被应用到状态机后响应给客户端
• Leader在收到更高任期的请求后转换为Follower

Followers

• 所有节点初始状态都是Follower角色
• 响应来自Leader和Candidate的RPC请求
• 如果在选举超时周期内没有收到AppendEntries的请求或者给Candidate投票，转换为Candidate角色

Candidates

• 超时时间内没有收到Leader的请求则转换为candidate角色，开始选举：
  • 递增currentTerm
  • 给自己投票
  • 重置选举时间
  • 发送RequestVote给其他所有节点
• 如果收到了大多数节点的选票，转换为Leader节点；发现Leader或者收到更高任期的请求则转换为Follower
• 如果收到Leader节点的AppendEntries请求，转换为Follower节点
• 如果选举超时，重新开始新一轮的选举

3.任期

Raft把时间切割为任意长度的任期，每个任期都有一个任期号，采用连续的整数。

每个任期都由一次选举开始，若选举失败则这个任期内没有Leader；如果选举出了Leader则这个任期内有Leader负责集群状态管理。

 

三、Raft协议特征

    Raft 算法和Paxos 不同之处，主要有 2 点：

1.在 Raft 中，不是所有节点都能当选领导者，只有日志较完整的节点（也就是日志完整度不比半数节点低的节点），才能当选领导者；

2.在 Raft 中，日志必须是连续的。Raft 算法通过任期、领导者心跳消息、随机选举超时时间、先来先服务的投票原则、大多数选票原则等，保证了一个任期只有一位领导，也极大地减少了选举失败的情况。

Paxos可以同时提交和处理多个提案，但是发生冲突时，理论上会有更高的延时（协商时间），而Raft算法会天生地把消息确定一个先后顺序。大幅减少了冲突的可能性。

本质上，Raft 算法以领导者为中心，选举出的领导者，以“一切以我为准”的方式，达成值的共识，和实现各节点日志的一致。