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

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值