etcd的raft算法笔记

etcd是一个在分布式环境下的key value存储服务，用于共享信息配置，服务发现，网上看了一些etcd的raft算法文章，做点笔记。

在raft状态有，leader，follower，candidate。

刚开始，所有node都是follower的混乱状态，当follower没有收到leader的心跳导致超时就会改成candidate状态，向其他节点发送投票请求，只有拿到半数以上节点的票数才能成为leader，当有多个candidate参选并票数一致时，会等下一轮投票，每个candidate会等待一个随机时间后重新发起投票请求，因为等待时间随机避免同时多个candidate选举的情况，可以选出唯一的leader，然后leader的步进数会加增加。

当leader挂掉后，其他节点收不到leader的心跳请求就会再次发起投票流程选举leader。

而follower的挂掉不会影响整体的运行。

当网络不稳定导致部分节点访问不了时，其他节点选取新的leader，出现脑裂问题时，网络环境里出现多个leader，新的leader由于步进数更大，旧的leader会变成follower，并被同步新leader的数据。

然后是日志同步复制的问题。follower可以执行读操作的负载均衡，但写操作都要经过leader节点，leader先记录操作到日志标记uncommit，然后同步到所有follower后并收到回应时，leader才会把记录标志为commit写入磁盘文件，然后告诉其他follower可以把记录也标记为commit了。

当leader节点收到一条日志记录，并同步到部分follower，这时如果leader挂了要，follower变成candidate重新选举leader，这时如果是没同步的follower成为leader就会漏数据，所以如果发起竞选的节点在上一个term中保存的已提交数据不完整，节点就会拒绝投票给它。

需要注意的是，etcd目前没有任何机制会自动去变化整个集群总共的节点数量，即如果没有人为的调用API，etcd宕机后的节点仍然被计算为总节点数中，任何请求被确认需要获得的投票数都是这个总数的半数以上。

etcd 节点的核心由三部分组成：

• Raft：raft 状态机是对 raft 共识算法的实现
• WAL：raft 日志存储
• Storage：数据的存储与索引

write ahead log所有的修改在提交之前都要先写入 log 文件中，是为了保证数据的一致性，可用于崩溃恢复，undo和redo操作等。随着使用量的增加，WAL存储的数据会暴增，为了防止磁盘很快就爆满，etcd默认每10000条记录做一次snapshot，经过snapshot以后的WAL文件就可以删除

下面是网上参考的文章地址

http://www.infoq.com/cn/articles/coreos-analyse-etcd

http://www.infoq.com/cn/articles/etcd-interpretation-application-scenario-implement-principle