浅谈分布式共识算法raft
作者:Yrion
出处:
前言:在分布式的系统中,存在很多的节点,节点之间如何进行协作运行、高效流转、主节点挂了怎么办、如何选主、各节点之间如何保持一致 , 这都是不可不面对的问题,此时raft算法应运而生,专门 用来解决上述问题 。 对于分布式的一致性算法,著名的有paxos,zookeeper基于paxos提出了zab协议, paxos是出名的晦涩难懂.而raft的设计初衷就是容易理解和简单、高效,本篇博客我们就来循序渐进的看看raft到底是什么?它的运行原理是什么样的?
本篇博客的目录:
一:raft的状态二:选主过程三:如何保证集群一致性四:如何处理脑裂问题五:总结一:raft的状态raft的集群角色分为3种,不同的节点在运行环境中处于不同的角色 , 任何节点的任何一个时刻都处于以下三种角色之一,不同的角色具有不同的功能 , 所承担的职责也不一样:
①:followerfollwer是集群的初始状态,所有的节点在刚开始加入到集群中,默认是follower的角色,也就是从节点~
②:candidatecandidate的含义可以理解为候选人,这是专门用于在follower在进行选举的时候,被投票者的称谓,这是一个中间角色,followerA会发起投票到followerB,此时followerA的角色就是candidate
③:leader有了从节点之后就必须有主节点了,所以接下来伴随的是选主的过程,选主之后的节点称之为leader,也就是主节点 , 主节点只有一个,由leader接收用户的请求,每一次请求都被被记录到log entry中
三个角色可以这样理解:试想新学期开学第一天,所有的同学都是普通学生的身份( follower ) , 新学期开始需要挑选出班长(leader),需要进行投票,大家先选出几个候选人,候选人可以自己投票给自己,此时要选中成为班长的这几个人就是 candidate, 最后经过选举出来的班长就是 leader
任期:任期简称Term,是raft里面非常重要的概念,每个任期可以是任意时长 , 任期用连续的整数进行标号,每个节点都维护着当前的任期值,每个节点在检测到自己的任期值低于其他节点会更新自己的任期值 , 设置为检测到的较高值 。 当leader和candidate发现自己的任期低于别的节点 , 则会立即把自己转换为follower
下面是几种角色的流转图:
文章插图
二:raft的选主2.1:leader负责处理客户端的请求所有对日志的添加或者状态变化的操作都是通过leader来完成,当leader接收请求之后会将日志分发到集群的所有follower节点,日志的数据流是从leader到其他的节点,而不会产生follower流向日志的情况 , raft会保证流向所有follower节点的日志副本都是一致的:
选举leader发生在以下两种情况:
①当一个raft集群初始化的时候 ②当选举出来的主节点宕机、崩溃的时候
2.2:接下来谈一谈raft是如何选主的:一个 Raft 集群开始 , 集群中的节点所有的初始状态都是 Follower, 然后设置任期(term为0),并启动计时器发起选举(Election),开始选举之后每个参与方都会有一个随机的超时时间( Election Timeout ),这里的关键就是随机 T imeout( 150ms 到 300ms之间 ), 最先走完 timeout时间的一个节点开始 发起投票 , 向还在 timeout 中的另外节点请求投票(Reuest Vote)并等待回复 , 此时它就只能投给自己 , 然后raft会统计得票数,在计数器时间内,得票最多的会成为leader.这样的结果就是最先发起投票的节点会有大概率成为主节点,选出 Leader 后 , term值会+1 , 并且 Leader 通过定期向所有 Follower 发送心跳信息(官方称之为:Append Entries,Append Entries是一种RPC协议)保持连接 。
文章插图
两个节点同时发起选举因为follwer节点的超时时间是随机的,所以可能会存在两个节点正好随机到相同的random time , 并且拥有相同的term,此时raft会如何处理呢?raft会在相同的random time out时间同时发起leader选举,因为两个Candidate存在相同的term和timeout , 并且同时发起投票,最终他们得到的votes是相同的 。 这个时候raft会等待下一轮的重试,下一轮两个节点的time out可能会不同,重试直到选举出leader
2.3:当选举完成之后考虑以下几个情形:情形一:leader宕机每次当leader对所有的followe发出Append Entries的时候,follower会有一个随机的超时时间,如果再超时时间内收到了leader的请求就会重置超时时间,如果没有收到超过超时时间,follower没有收到 Leader 的心跳 , follower会认为 Leader 可能已经挂了 , 此时第一个超时的follower会发起投票,注意这个时候它依然会向宕机的原leader发出Reuest Vote,但原leader不会回复 。 raft设计的
- 中国|浅谈5G移动通信技术的前世和今生
- 内容|浅谈内容行业的一些规律和壁垒,聊聊电商平台孵化小红书难点(外部原因)
- 浅谈如何开好一家手机维修店(六):指南舟手机维修培训学校
- 分布式锁的这三种实现90%的人都不知道
- 巨杉亮相 DTCC2019,引领分布式数据库未来发展
- Martian框架发布 3.0.3 版本,Redis分布式锁
- 为什么分布式应用程序需要依赖管理?
- 大规模分布式强化学习基础架构Menger, 大幅提高真实任务的学习效率
- 手机应用篇:浅谈手机内存卡的优劣好坏真假及应用
- 分布式云对智能化战争有何影响