Raft算法

分布式一致性问题

假如现在有一个单节点的系统，可以假设这个 节点 是一个数据库，并且存储了一个数值（x），然后，我们还有一个客户端，它可以操作数据库修改数值，在这种只有一个节点的情况下，数值达成一致是比较容易实现的，但是，在有多个节点的情况下，如何实现一致呢，这个问题就是所谓的 分布式一致性问题，而 Raft算法 就是为了解决分布式一致性问题

Raft算法如何工作

在Raft算法中，一个节点会在三种角色状态之间变化，这三种角色分别是: Follower state,（跟随者 角色）， Candidate state（候选人 角色）， Leader state（领导者 角色，初始化时，所有的节点都是跟随者），如果一段时间后，跟随者没有监听到领导者发来的消息，那么自己将变成候选人身份，随后，候选人将向其它节点发起一次选举投票请求，接收到的节点会回复（响应）这次投票，如果大多数节点都投票赞同，那么这个候选人将成为"领导人"，这个过程叫 领导人选举，这之后所有的变化指令都由这个领导人来决定，每次更改指令会先记录到节点的日志里，不过要注意的是，这条记录日志还没有被提交，所以还不会更改节点的值

然后在提交之前，领导人节点会将变更指令同步到跟随者的节点日志中

随后领导人进入等待状态，直到收到大多数节点记录成功的响应

这时，领导人将提交这条记录，当前存储的值变为5，然后领导人通知所有跟随者提交记录

最终，集群状态达成一致了，这个两次提交（2PC）的过程叫作 日志复制

Leader选举

Raft 使用心跳（heartbeat）触发Leader选举。当服务器启动时，初始化为Follower。Leader向所有Followers周期性发送heartbeat。如果Follower在选举超时时间内没有收到Leader的heartbeat，就会等待一段随机的时间后发起一次Leader选举
Follower将其当前term加一然后转换为Candidate。它首先给自己投票并且给集群中的其他服务器发送 RequestVote RPC 。结果有以下三种情况：

赢得了多数的选票，成功选举为Leader；
收到了Leader的消息，表示有其它服务器已经抢先当选了Leader；
没有服务器赢得多数的选票，Leader选举失败，等待选举时间超时后发起下一次选举

日志同步

Leader选出后，就开始接收客户端的请求。Leader把请求作为日志条目（Log entries）加入到它的日志中，然后并行的向其他服务器发起 AppendEntries RPC 复制日志条目。当这条日志被复制到大多数服务器上，Leader将这条日志应用到它的状态机并向客户端返回执行结果

Raft算法优点

1. 强一致性：所有节点的数据并非实时一致，但Raft算法保证Leader节点的数据最全，同时所有请求都由Leader处理，所以在客户端角度看是强一致性的
2. 高可靠性：客户端收到请求成功即代表数据不再改变。Committed日志在大多数节点上冗余存储，少于一半的磁盘故障数据不会丢失
3. 高可用性：从Raft算法原理可以看出，选举和日志同步都只需要大多数的节点正常互联即可，所以少量节点故障或网络异常不会影响系统的可用性