Raft分布式⼀致性算法原理（选举和同步）
Raft分布式⼀致性算法原理(选举和同步)
⼀. 背景
在集群环境下，很容易出现单节点故障的问题，那么我们就需要进⾏集群部署，但是当集群部署的环境下，我们如何保证⼯作有序的调度与通信并且保证⼀致性呢，当客户端发送⼀连串指令，我们需要在集群环境下，所有服务机器最终要保证⼀致性，⽽且在出现⼀系列异常并且恢复之后的情况下，仍然要保证 最终状态的⼀致性(状态机)
最终状态的⼀致性(状态机) ，于是就引出了分布式⼀致性协议。
Zookeeper 采⽤的就是Paxos协议，只不
Paxos 协议，因为我们最常⽤的 Zookeeper
在说到 分布式⼀致性协议
分布式⼀致性协议 ，多数⼈第⼀个想到的就是⼤名⿍⿍的 Paxos
过对Paxos进⾏了改造，⽽且Google的很多⼤型分布式系统都采⽤了Paxos算法来解决分布式⼀致性问题，但是由于Paxos对于初学者来说很不
Raft 分布式⼀致性协议，有意思的是，raft协议的两为创作者起容易理解，Paxos的最⼤特点就是难，不仅难以理解，更难以实现，因此诞⽣了 Raft
初也是因为Paxos协议不容易理解和实现，于是Raft被迫营业了。
具有⼀致性，⾼可⽤且去中⼼化的分布式⼀致性协议 ，⽐如现在⽐较流⾏的 etcd分布式存储
etcd分布式存储(共识算法) 是⽬前使⽤⽐较⼴泛的 具有⼀致性，⾼可⽤且去中⼼化的分布式⼀致性协议
Raft协议 (共识算法)
仓库 组件就是使⽤raft协议实现分布式⼀致性的，在本⽂中主要介绍⼏个⽅⾯：
仓库
复制状态机
raft的基本概念
raft主从选举原理
raft数据同步原理
⼆. 复制状态机
何为复制状态机，⾸先状态机就是每个节点都是具有状态的，且状态机是确定性的，不同的状态对应不同的⾓⾊和需要在该状态下的⼀系列操作，这个状态可能是临时的，可能是长时间保持的，但是状态机都是为了实现容错和⼀致性所设计的，那么复制状态机就是在状态机的基础上增加同步复制的功能，在同步复制的时候，每个节点可以在缓存或者磁盘保存同步复制的位置和顺序，该模型⼀句话描述就是： 多个节点上，从相同的
多个节点上，从相同的初始状态开始，执⾏相同的⼀串命令，产⽣相同的最终状态。 所以状态机需要实现以下⽅法：
初始状态开始，执⾏相同的⼀串命令，产⽣相同的最终状态。
在多个独⽴的服务器上放置状态机的副本。60英语
接收客户端请求，解释为输⼊到状态机。
选择输⼊的顺序。
在每台服务器上按所选顺序执⾏输⼊。
通过状态机的输出响应客户端。
监视状态或输出差异的副本
log 实现复制和⼀致性。
这就是复制状态机的逻辑图，利⽤ state machine
state machine 和 log
三. raft的基本概念
1. 三个状态
leader(领导者)
表⽰该节点是主节点，该节点主要处理与客户端的通讯和交互，还有与follower从节点的的数据同步与⼼跳机制的维护。
follower(追随者)
表⽰该节点是从节点，该节点主要负责转发客户端的请求到leader节点，然后保持与leader节点的数据同步。
candidate(候选者)
表⽰该节点是选举主节点的候选⼈，该节点状态下表⽰现在是选举主从节点的时间点，作为候选⼈，既有可能成为leader，也有可能成为follower，具体的选举原理，下⽂会详细介绍。
这三种状态的转换图：
2. Term和vote概念
电音是什么term属性表⽰投票的轮数，也可以理解是任期数，term⽤连续的数字进⾏表⽰。当然了，该属性⼀般会持久化到磁盘中，在所有节点刚开始的时候或者在重新选举的时候会进⼊candidate状态，进⾏选举投票，每⼀轮投票之后term都会加1，从下图可以看出来，不管这⼀轮选举是否成功选出leader，只要⼀轮结束，term都会加1。
⽽vote属性就是代表各个节点投票的时候，该节点选择投的那个节点，每个节点在收到投票请求的时候，就是根据request vote进⾏统计和判断是否⾃⼰成为leader的依据和条件。
3. log与index概念
index索引
log⽇志每个节点都持有⼀份，并且是⽤来保证⼀致性和容错性的，⾸先来看下图。从这张图可以看出来，每个⽇志⽂件包含： index索引
号，term任期号，以及term任期号下的数据信息，这么做的好处是为了节点启动后容错检查和主从同步的⼀致性 ，下⽂会详细介绍。号，term任期号，以及term任期号下的数据信息，这么做的好处是为
了节点启动后容错检查和主从同步的⼀致性
4. RPC协议类型
AppendEntries RPC leader使⽤AppendEntries RPC同步⽇志数据给其它follower, (⼼跳是没有⽇志记录的AppendEntries RPC)。
作文700RequestVote RPC Candidate状态的时候所有节点通过发送RequestVote RPC来发起选举。
InstallSnapshot RPC 正常情况下leader是使⽤AppendEntries RPC同步⽇志数据，但是当⼀个follower落后leader太多时，raft会使⽤InstallSnapshot RPC 来使其快速补充数据。
后患5. ⼩结
在这⼀节主要介绍了raft协议的三种状态，term任期概念，以及log⽇志和index索引的概念，在介绍完这些基础概念之后，可能⼤家还是⼀头雾⽔，别着急，介绍这些基本概念是为了在介绍下⾯的主从选举和数据同步做铺垫，下⾯开始进⼊核⼼内容。
四. 主从选举原理
过半选举 的机制，所以我们推荐raft的实现同ookeeper⼀样，也是奇数个节点部署。⾸先，我们需要知道的是，raft和zookeeper⼀样都采⽤ 过半选举
现在，我们假设开始部署三个服务节点：
term 在这三个节点进⾏启动的时候， ⾸先进⼊candidate(候选者)的状态
须字草书
⾸先进⼊candidate(候选者)的状态 ，然后进⾏投票选举，这个时候，所有的节点都会在本地创建⼀个 term
随机数的倒计时(150~300ms) ，当这个倒计时结束的时属性，并且初始化值为0 ，表⽰还没有开始选举投票，然后每个节点都会设置⼀个 随机数的倒计时(150~300ms)
属性，并且初始化值为0
候，第⼀个倒计时结束的节点会率先发起投票，并且投票给⾃⼰，即携带（vote = ⾃⼰）的投票请求给其他两个节点。
假设节点C的倒计时先结束，它率先发起了投票，则节点C将⾃⼰的term从0置为1，并且vote票投给⾃⼰，然后将这些参数包装发送给节点A和节点B，这个时候节点A和B还没有结束倒计时：
节点A和B在收到C的投票请求之后，⾸先会⽐较收到的term和⾃⼰的term作⽐较，如果发现接收到的t
erm数值⽐⾃⼰的⼤，则会放弃⾃⼰的投票，把⾃⼰的票(vote)投给第⼀个接收到的投票请求，即节点A和B在收到C的请求之后，⽐较发现⾃⼰的term为0，⽽接收到的term为1，则会把⾃⼰的vote置为节点C，然后响应请求：
当节点C收到了节点A和节点B的响应(ack)和投票信息(vote)，则会计算票数，由于过半选举的机制，⼀个节点需要成为leader节点，必须得到 ((
3票 ，则满⾜条n/2 +1 ) 的票数，这⾥n=3，即得到2票就可以当选leader节点，⽽C节点收到了节点A和B的两票，再加上⾃⼰的⼀票，总共 3票
乘法的初步认识教学设计
n/2 +1 )
从candidate(候选件，当选leader，当选leader之后，向节点A和B发送⼼跳包，并且告诉它们⾃⼰ 成为了leader节点
武汉有什么景点成为了leader节点 ，那么节点A和B就会 从candidate(候选者)状态转为follower(追随者) 状态，并开始
正常⼯作流程了：
者)状态转为follower(追随者)
回忆往事的句子
正常情况下，选举就已经结束了，那么如果遇到异常情况呢，现在假设leader节点发⽣了故障宕机了，这⾥就要强调⼀个点，就是每个follower节点在和leader节点维持⼼跳的时候，都会设置⼀个 超时时间(timeout)
超时时间(timeout) ，当follower节点在等待leader节点的⼼跳请求的时候如果超过了这个
重新进⼊candidate状态 ，然后重新选举leader：
超时时间，就会认为leader出现了异常，进⽽会 重新进⼊candidate状态
从上图可以看出来，现在假设节点B经过上⾯的流程然后成为了新的leader节点，这个时候节点A和节点B的term(任期数)从1增加到了2，但是由于节点C的宕机，节点C的term还是原来的1，这么做的好处就是当节点C重新启动的时候，发现⾃⼰的term已经落后了，那么就不能成为leader，就等待新的leader将新的数据同步给⾃⼰，不会出现数据丢失的情况。
