6.824——实验二：Raft

1.介绍

这是构建KV存储系统一系列实验的第一个实验。而对于分布式数据库而言，首先要解决两个重大的问题：容错、一致性。所以这个实验当中，需要实现Raft协议（一个复制状态机协议）以解决这两个首要问题。

一个可靠性服务需要通过存储其状态副本（比如数据等）到多个副本服务器上来实现容错。即使一些服务器节点失败了，其它副本服务器仍可以运行该服务。但问题的关键是，失败的服务节点会造成数据不一致。
下一个实验会在基于Raft协议之上构建kv服务，然后可以在多机环境上共享kv服务，以求更高的性能。

2.Raft

为了解决上面的问题即一致性问题，于是出现了Raft，Raft能够管理所有服务节点的状态副本，能够让失败的服务节点恢复到正确的一致性状态上来，算法的目标就是让服务器节点按照少数服从多数的方式，最终达成一致意见。正如上面讲到的，Raft是一个复制状态机协议。https://yuerblog.cc/2018/07/28/understand-raft/——这篇博客不错，raft关键在于抽屉理论，二阶段提交，选举约束，一共3个部分。
【下面仔细说一下Raft的原理】
在GFS中我们说过一致性的实现原理——确定一个主实例，串行化所有写操作，然后在其他实例重放相同的操作序列，以保证多个实例数据的一致性。但是GFS中只有一个主实例master，一旦master崩溃，这会造成很大的影响，所以一般GFS都还会有些备用master，需要在这些备用master上同样同步保存配置信息和日志信息。

虽然大体上Raft协议也是确定一个主实例Leader，但不同的是其不需要额外的备份Leader，因为其他的所有节点都可以成为Leader。
下面描述一下Raft的大体流程，在一台Leader服务器上，一致性模块（这里就是Raft）接收到客户端的指令并把指令整理后写入到日志中，并与其他Follower服务器上的一致性模块（Raft实例）通信，以确保每一个日志最终包含一致的请求序列，即使有某些服务器宕机。一旦这些指令被正确的复制了，每一个服务器的状态机都会按同样的顺序去执行它们，然后将结果返回给客户端。另外，如果某些服务器宕机后又重新恢复了，其Raft会主动和Leader服务器通信，及时更新本地log并执行相应的命令序列，保持状态一致性。
http://thesecretlivesofdata.com/raft/ 这个链接超级棒，讲得很详细。总结一下Raft的三个主要子问题：
【1. 日志复制】
这里我们首先说一下每一个服务器上日志记录的形式：term+command。

对于整个系统而言，所有的改变都要经由Leader来实现。在一台Leader服务器上，一致性模块（这里就是Raft）接收到客户端的指令并把指令整理后写入到日志中，此时，该条日志记录还处于未提交状态，节点并不会执行具体操作；而是在提交之前首先与其他Follower服务器上的一致性模块（Raft实例）通信，以确保每一个日志最终包含一致的请求序列，再等待大多数节点写入log并响应Leader之后，Leader才commit执行具体操作，然后Leader通知其他节点commit。

【2. Leader选举】

• 对于集群中的每个节点而言，有3种状态——Follower、Candidate、Leader。
• 初始时都为follower状态，如果follower节点在一段时间内没有收到命令（即当前Leader宕机了），就会变为Candidate状态；然后Candidate节点会向其他节点发起投票请求，如果该Candidate节点得到了大多数的vote支持，就会变为Leader。
• 超时设定：
  election timeout.——若超过这个时间还没有接到Leader的命令（心跳检测或log增加等RPC调用），则代表Leader可能挂掉了，于是自己就可以准备上位了

Raft的关键就在于Leader选举机制&