平面设计的网站,网站开发原型 图,做网站找哪家公司最好,深圳品牌手表有哪些注#xff1a;本文原创#xff0c;转载请标明出处。欢迎转发、关注微信公众号#xff1a;Q的博客。 不定期发送干货#xff0c;实践经验、系统总结、源码解读、技术原理。本文目的笔者期望通过系列文章帮助读者深入理解Raft协议并能付诸于工程实践中#xff0c;同时解读不…注本文原创转载请标明出处。欢迎转发、关注微信公众号Q的博客。 不定期发送干货实践经验、系统总结、源码解读、技术原理。本文目的笔者期望通过系列文章帮助读者深入理解Raft协议并能付诸于工程实践中同时解读不易理解或容易误解的关键点。该系列会从原理、源码、实践三个部分为大家讲解Raft算法本文为《Raft实战》系列第二篇原理部分我们会结合 Raft 论文讲解 Raft 算法思路整体分篇会遵循 Raft 的模块化思想分别讲解 Leader election、Log replication、Safety、Cluster membership change、Log compaction 等。源码部分我们会通过分析 hashicorp/raft 来学习一个工业界的 Raft 实现hashicorp/raft 是 Consul 的底层依赖。实践部分我们会基于 hashicorp/raft 来实现一个简单的分布式 kv 存储以此作为系列的收尾。什么是选主选主(Leader election)就是在分布式系统内抉择出一个主节点来负责一些特定的工作。在执行了选主过程后集群中每个节点都会识别出一个特定的、唯一的节点作为leader。我们开发的系统如果遇到选主的需求通常会直接基于 zookeeper 或 etcd 来做把这部分的复杂性收敛到第三方系统。然而作为 etcd 基础的 raft 自身也存在“选主”的概念这是两个层面的事情基于 etcd 的选主指的是利用第三方 etcd 让集群对谁做主节点的决策达成一致技术上来说利用的是 etcd 的一致性状态机、lease 以及 watch 机制这个事情也可以改用单节点的 MySQL/Redis 来做只是无法获得高可用性而 raft 本身的选主则指的是在 raft 集群自身内部通过票选、心跳等机制来协调出一个大多数节点认可的主节点作为集群的 leader 去协调所有决策。当你的系统利用 etcd 来写入谁是主节点的时候这个决策也在 etcd 内部被它自己集群选出的主节点处理并同步给其它节点。Raft 为什么要进行选主按照论文所述原生的 Paxos 算法使用了一种点对点(peer-to-peer)的方式所有节点地位是平等的。在理想情况下算法的目的是制定一个决策这对于简化的模型比较有意义。但在工业界很少会有系统会使用这种方式当有一系列的决策需要被制定的时候先选出一个 leader 节点然后让它去协调所有的决策这样算法会更加简单快速。此外和其它一致性算法相比raft 赋予了 leader 节点更强的领导力称之为 Strong Leader。比如说日志条目只能从 leader 节点发送给其它节点而不能反着来这种方式简化了日志复制的逻辑使 raft 变得更加简单易懂。Raft选主过程下图的节点状态转移图我们在前一篇文章已经看到了但只是做了简单的描述接下来我们会结合具体的Leader election细节来深刻理解节点的状态转换。*图名节点状态图Follower状态转移过程Raft 的选主基于一种心跳机制集群中每个节点刚启动时都是 follower 身份(Step: starts up)leader 会周期性的向所有节点发送心跳包来维持自己的权威那么首个 leader 是如何被选举出来的呢方法是如果一个 follower 在一段时间内没有收到任何心跳也就是选举超时那么它就会主观认为系统中没有可用的 leader并发起新的选举(Step: times out, starts election)。这里有一个问题即这个“选举超时时间”该如何制定如果所有节点在同一时刻启动经过同样的超时时间后同时发起选举整个集群会变得低效不堪极端情况下甚至会一直选不出一个主节点。Raft 巧妙的使用了一个随机化的定时器让每个节点的“超时时间”在一定范围内随机生成这样就大大的降低了多个节点同时发起选举的可能性。*图解一个五节点Raft集群的初始状态所有节点都是follower身份term为1且每个节点的选举超时定时器不同若 follower 想发起一次选举follower 需要先增加自己的当前 term并将身份切换为 candidate。然后它会向集群其它节点发送“请给自己投票”的消息(RequestVote RPC)。*图解S1 率先超时变为 candidateterm 1并向其它节点发出拉票请求Candicate状态转移过程Follower 切换为 candidate 并向集群其他节点发送“请给自己投票”的消息后接下来会有三种可能的结果也即上面节点状态图中 candidate 状态向外伸出的三条线。1. 选举成功(Step: receives votes from majority of servers)当candicate从整个集群的大多数(N/21)节点获得了针对同一 term 的选票时它就赢得了这次选举立刻将自己的身份转变为 leader 并开始向其它节点发送心跳来维持自己的权威。*图解“大部分”节点都给了S1选票*图解S1变为leader开始发送心跳维持权威每个节点针对每个 term 只能投出一张票并且按照先到先得的原则。这个规则确保只有一个 candidate 会成为 leader。2. 选举失败(Step: discovers current leader or new term)Candidate 在等待投票回复的时候可能会突然收到其它自称是 leader 的节点发送的心跳包如果这个心跳包里携带的 term 不小于 candidate 当前的 term那么 candidate 会承认这个 leader并将身份切回 follower。这说明其它节点已经成功赢得了选举我们只需立刻跟随即可。但如果心跳包中的 term 比自己小candidate 会拒绝这次请求并保持选举状态。*图解S4、S2 依次开始选举*图解S4 成为 leaderS2 在收到 S4 的心跳包后由于 term 不小于自己当前的 term因此会立刻切为 follower 跟随S43. 选举超时(Step: times out, new election)第三种可能的结果是 candidate 既没有赢也没有输。如果有多个 follower 同时成为 candidate选票是可能被瓜分的如果没有任何一个 candidate 能得到大多数节点的支持那么每一个 candidate 都会超时。此时 candidate 需要增加自己的 term然后发起新一轮选举。如果这里不做一些特殊处理选票可能会一直被瓜分导致选不出 leader 来。这里的“特殊处理”指的就是前文所述的随机化选举超时时间。*图解S1~S5都在参与选举*图解没有任何节点愿意给他人投票*图解如果没有随机化超时时间所有节点将会继续同时发起选举……以上便是 candidate 三种可能的选举结果。Leader 切换状态转移过程节点状态图中的最后一条线是discovers server with higher term。想象一个场景当 leader 节点发生了宕机或网络断连此时其它 follower 会收不到 leader 心跳首个触发超时的节点会变为 candidate 并开始拉票(由于随机化各个 follower 超时时间不同)由于该 candidate 的 term 大于原 leader 的 term因此所有 follower 都会投票给它这名 candidate 会变为新的 leader。一段时间后原 leader 恢复了收到了来自新leader 的心跳包发现心跳中的 term 大于自己的 term此时该节点会立刻切换为 follower 并跟随的新 leader。上述流程的动画模拟如下*图解S4 作为 term2 的 leader*图解S4 宕机S5 即将率先超时*图解S5 当选 term3 的 leader*图解S4 宕机恢复后收到了来自 S5 的 term3 心跳*图解S4 立刻变为 S5 的 follower以上就是 raft 的选主逻辑但还有一些细节(譬如是否给该 candidate 投票还有一些其它条件)依赖算法的其它部分基础我们会在后续“安全性”一篇描述。当票选出 leader 后leader 也该承担起相应的责任了这个责任是什么就是下一篇将介绍的“日志复制”~欢迎转发、关注微信公众号Q的博客不定期发送干货实践经验、系统总结、源码解读、技术原理。
