Raft笔记

内容参考自：解读共识算法Raft（1）简介和状态简化

出自Lamport的《In Search of an Understandable Consensus Algorithm》

1. Raft把共识算法分为三个子问题：Leader Election、Log Replication、Safety

2. 状态简化。只有三个状态，并且通信只通过两类RPC完成。

复制状态机（RSM Replication State Machine）

相同的初始状态+相同的输入=相同的结束状态。即“在多个节点上面，从相同的初始状态执行相同的一串命令，一定会产生相同的结束状态”。

Leader将客户请求command封装到一个个log entry日志实体中，将log entries复制到所有的follower节点，大家按照相同的顺序应用log entries中的command，根据复制状态机理论，大家的结束状态一定是一致的。Client无论查询哪个节点的状态机，只要节点应用了日志，那么查询结果就是一样的。

使用共识算法就是为了实现复制状态机，因为一个分布式场景下的各节点间，就是通过共识算法来保证命令序列的一致，从而始终保持它们的状态一致，从而实现了高可用。

复制状态机和主备复制：

复制状态机更强大，例如，两个副本，一个行存储，一个列存储，它们初始数据相同，那么只要持续发给它们相同的命令，那么同一时刻从两个副本中读取到的结果也是一样的，这是一种HTAP的实现方法。

状态简化

任何时刻，每一个服务器节点处于Leader、Follower、Candidate三个状态之一。相比Paxos，Raft只需要考虑状态之间的切换，不需要考虑状态之间共存和互相影响。

1. 任何节点启动时都是follower状态。
2. 如果察觉到集群中没有Leader的话，它会把自己从follower状态切换到candidate状态。
3. 在candidate中经历一次或者多次选举，最终根据选举的结果决定自己切换到leader状态，或者切换回follower状态。选举成功就切换到Leader状态，并在Leader状态下为客户端提供服务。
4. 如果在Leader状态下的任期已经结束，或者自身发生宕机或者其它问题，那么它会切换到follower状态并进行下一次循环。

Raft把时间划分为多个任期，每一个任期都以一次选举开始，如果选举没有选举出Leader就会重新开始一个任期以及新的一次选举。

Raft算法中服务器节点之间使用RPC进行通信，Raft中只有两种主要的RPC。

1. RequestVote RPC。由Candidate在选举期间发起。

2. AppendEntries RPC。由Leader发起，用来复制日志和提供一种心跳机制。

Raft为RPC提供了其他功能，服务器之间通信的时候会交换当前的任期号。用来更新为较大的任期号。

如果一个Candidate或者Leader发现自己的任期号过期了，就会回到Follower状态。

领导者选举

Raft内部有一种心跳机制，如果存在Leader，那么这个Leader就会周期性地向所有follower发送心跳来维持自己的地位，如果follower一段时间没有收到心跳，那么他就会认为系统中没有可用的leader了，然后开始进行选举。