前
我还是想简单记录一下raft算法，很多分布式系统都用到了，至于paxos就算了，没理解
正
raft算法
raft算法在我的理解中，主要用于管理分布式中多副本的情况，即系统有多个节点，其中有一个节点进行读写，其他节点只进行读或者只负责同步，当主节点下线后，需要选举出一个新的节点，当然这是具体的用处了，raft的定义中，将它的功能分为多个子问题，leader选举，日志同步，安全性，日志压缩，成员变更。
成员
raft中的角色分为3种， leader， follower， candidate
- leader负责接收客户端请求，并向follower同步请求日志，当日志同步到大多数节点后告诉follower提交日志
- follower接收并持久化同步的日志，在leader告知后提交后，提交日志
- candidate，选举过程中的历史角色
状态转换
当follower超时没有收到leader的消息，它会变成candidate开始leader选举，收到大多数服务器投票的成为新的leader。
raft算法有任期（term）的概念，多个任期之间是leader选举，如果选举失败会跳过这个任期leader选举
raft通过心跳出发leader选举，当服务器启动时，初始时follower，leader定期向follower发送心跳，如果follower超时没有收到心跳，就会等待随机时间发器一次选举。
首先将自己的任期+1，然后转换为candidate，首先给自己投一票，并且给其他节点发送“拉票”请求，其他节点收到请求会，会有3个原则
- 每个任期每个节点只有一票
- 候选人知道的信息不能比自己少（日志提交记录）
- 先到先得，只能给先来的那个
当candidate发送请求后，会得到3种结果， - 得票超过一半（majority），赢得选举，成为leader，向其他节点发送心跳说明
- 被告知别人当选，自己切换到follower
- 没有收到足够的票，重新发出选举，任期+1
如果发生平票，则会等待然后重新进入选举，降低了系统可用性，所以每个节点发出选举请求时会等待随机时间，然后节点数量时奇数，尽量减少平票。
日志同步
当有leader后，就开始接收客户端请求，leader把请求作为日志驾到日志中，然后向其他服务器发送AppendEntries复制日志条目，当大多数服务器复制成功后，leader提交该日志并向客户端返回。
对于没有复制成功的服务器，leader会不断重试。
安全性
raft新增两条限制保证安全性
- 拥有最新提交的节点才有资格成为leader，发送拉票请求时，会带上自己的提交index和任期，目标机器会先比较任期，然后比较index，然后投票
- leader只会推进当前任期已经复制到大多数的服务器的日志
###
todo…
