etcd raft模块解析（一）

#分布式一致性算法

选主算法是保证在2n+1数量的集群中可以保证最多n个节点宕机时依然可以保证服务可用，并且在宕机的服务器启动后可以加入集群继续使用

第一个被共识的算法是Paxos算法，zookeeper就是使用这种算法。但是Paxos算法过于复杂，于是有了raft算法。
etcd就是选用raft算法来实现分布式一致性的

###raft算法的实现
下面是节点状态的切换图。

#####任期Term

初始个节点任期都是一样，并且选出learder后节点们都会统一他们的任期。每个节点也会存储他们同步的日志index

选举使用一个每个节点设置随机的超时时间（Timeout）完成的。首先每个节点与leader进行心跳通信，并且每次通信后都会重置Timeout为值，重新倒计时。
如果Timeout倒计时到0时，则此节点认为leader已下线，开始选举。会把自己的任期号加一 。随机的Timeout应设置为大于心跳间隔一个数量级，已防止因为网络延迟迟到的心跳包让节点认为leader已下线。

开始选举，此节点会先投票给自己，然后给所有其他节点发送请求让他们来选举自己，会带上自己的任期号和最后一条日志index。如果其他节点之前没给任何人投票，并且任期号<=接收请求的任期号，并且日志index>=接到到index，那么他将获得这一票。如果他获得了半数以上的投票则他成为leader。如果没有任何一个节点获得半数投票则开启下一任期选举。

所以这个选举的原理就是看那个节点先感知leader下线，抢在其他节点前发送投票请求取得半数投票。而谁先感知则由每个节点设置的随机Timeout来决定。

因为是靠随机来做的算法，所以在极端情况下会重新几个节点同时发送投票请求，导致活锁的情况，不过连续多次极端情况的几率非常低

这个演示更加明了
http://thesecretlivesofdata.com/raft/
以上只是理论上的算法，实际还有一些特殊的点

###下面看一个问题
在选举时是通过任期号和索引index来判断 谁的日志更新 ， 谁的任期号大谁的新，同样任期号下谁的索引大谁新 这样会出现一个问题

如表格 t代表时间 一共有a,b,c,d,e五个节点 ,(x,y)代表（任期，数据）

初始状态t1 a为learder 用其他颜色表示，在t2时接受客户端写入了新的数据，并在同步过程中宕机 只同步了两个节点

• t3 时e竞选成了learder 因为大多数节点的任期和索引都和他一样新 之后接受了消息但是在写入自己后宕机
• t4 时a苏醒成了learder 因为他的任期和索引都比大多数新 然后他继续了之前数据的复制 并且复制到了大多数上 这个数据（1，7）应该是有效的
• t5 e苏醒并成为了learder 因为它最新一条数据的任期是2 然后它复制原来的消息（1，7）就丢失了 。

按理说这个a苏醒后应该是任期3 这样e就不会成为learder 。
这里的根本原因是获取任期要从日志里面最新的一条，因为a苏醒时没收到客户端请求没有新的日志所以其他节点存储的最新任期还是1其实应该是第3任期了。
比如节点d ，已经换了好次的leader了 但是因为这些leader没能写入数据 ，所以他记录的任期却还是1。
为了解决这个问题etcd有了一个限制：

每个节点竞选成learder后，要先同步一条空日志，这样一来大多数节点都能感知任期变动。

##PreVote
这是为避免发生无意义选举的一个机制，当learder没挂掉时，因为发生网络分区导致少数服务在一个分区内，他们因为连不上learder会不断的发起选举，任期号不断增加。导致网络分区恢复时他的任期号大于learder，从而发送选举，扰乱集群。

prevote 要求节点在开始选举前，必须先和所有其他节点进行一次通讯，如果超过了半数以上响应才能开始选举。
节点会先进入PreCandidate状态此时不会增加自己的任期号，当他可以和集群半数以上的节点通信时，才能进入Candidate状态开始正式选举
这样网络分区情况下，少数节点的分区不会不断发起选举也不会增加自己的任期号。