网站建设外包合同模板模板之家

当前位置： 首页 > news >正文

网站建设外包合同模板,模板之家,wordpress不显示文章的时间,儿童手工写在前面 在分布式之Paxos共识算法分析 一文中我们分析了paxos算法#xff0c;知道了其包括basic paxos和multi paxos#xff0c;并了解了multi paxos只是一种分布式共识算法的思想#xff0c;而非具体算法#xff0c;但可根据其设计具体的算法#xff0c;本文就一起来看…写在前面 在分布式之Paxos共识算法分析 一文中我们分析了paxos算法知道了其包括basic paxos和multi paxos并了解了multi paxos只是一种分布式共识算法的思想而非具体算法但可根据其设计具体的算法本文就一起来看下其一种具体的实现算法raft这也是当前中心化架构分布式系统使用最多的一种分布式共识算法了下面我们就一起看下吧 1raft提供了哪些内容 在multi paxos的描述中有一个霸道总裁的角色leader因此在raft中就定义了leader的选举策略。除此之外还定义了日志复制策略成员变更。接下来我们分别看下这三部分内容。 2leader选举 首先我们先来看下raft中节点的角色包括领导者跟随者非leader大部分时间所处的状态候选者竞选leader时所处的状态另外每个节点还有一个任期编号的属性代表当前集群的leader是第几任leader(可用于处理多leader场景以及leader选举投票确定是否投票)任期编号默认为0如下图 在系统初始状态所有节点所处的状态都是跟随者并且每个节点都有leader心跳消息的超时时间,该超时时间是随机的避免多节点同时到期并竞选leader导致无法快速选举leader的问题。如下节点A节点B节点C超时时间分别是150ms200ms300ms: 很明显节点A会先超时转换角色为候选人并将自己的任期编号1变为1其认为主节点故障需要产生新的leader因此任期编号1先向自己投1票并向其他节点发送申请成为leader消息如下图 其他节点发现自己的任期都小于1并且自己在term1都还没有投过票一个任期只能投一票即某任期一旦投过票在收到相同任期申请成为leader的请求则忽略或投拒绝票,因此会投出自己唯一的一票如下: 之后节点A获取了3票赞成票超过了3个节点的半数因此成为leader如下 接着leader就会周期性的给其他节点发送心跳消息防止其他节点的leader心跳超时时间到时并篡权如下图 以上过程源码参考这里 ,运行过程如下图 补充下其他的规则 1:领导者周期性地向所有跟随者发送心跳消息即不包含日志项的日志复制 RPC 消息通知大家我是领导者阻止跟随者发起新的选举。 2:如果在指定时间内跟随者没有接收到来自领导者的消息那么它就认为当前没有领导者推举自己为候选人发起领导者选举。 3:在一次选举中赢得大多数选票的候选人将晋升为领导者。 4:在一个任期内领导者一直都会是领导者直到它自身出现问题比如宕机或者因为网络延迟其他节点发起一轮新的选举。 5:在一次选举中每一个服务器节点最多会对一个任期编号投出一张选票并且按照“先来先服务”的原则进行投票。比如节点 C 的任期编号为 3先收到了 1 个包含任期编号为 4 的投票请求来自节点 A然后又收到了 1 个包含任期编号为 4 的投票请求来自节点 B。那么节点 C 将会把唯一一张选票投给节点 A当再收到节点 B 的投票请求 RPC 消息时对于编号为 4 的任期已没有选票可投了。 6:日志完整性高的跟随者也就是最后一条日志项对应的任期编号值更大索引号更大拒绝投票给日志完整性低的候选人。比如节点 B 的任期编号为 3节点 C 的任期编号是 4节点 B 的最后一条日志项对应的任期编号为 3而节点 C 为 2那么当节点 C 请求节点 B 投票给自己时节点 B 将拒绝投票。2.1常见问题 2.1.1如何知道选票超过半数 总节点数是固定的已知的进行简单数学运算即可。 2.1.2raft存在的问题 leader的单点问题以及由此带来的写数据性能瓶颈问题。节点较多时leader的心跳消息有较高的通信成本。节点较多时选主获得半数投票时间长集群不可用时间长。 2.1.3所有节点都可能成为leader吗 不是的必须当前节点的日志完整性高于超过半数的节点这样才可能获得半数以上选票但这里并不带代表这些节点不能成为candidate并发起选举只是说就算发起选举了最终也会选举失败而已。 2.1.4leader会一直是leader吗 如果是机器和网络一直正常的话是的但是实际环境并不会根据chubby团队观察一个leader的任期大概是在几天左右。 2.1.5如果集群重启集群状态如任期编号会清0吗 不会的这些信息是持久化存储的重启后需要将集群恢复到重启前的状态。 2.1.6如果某轮leader选举失败下一轮选举任期编号会1吗 会的因为一个任期一个节点只有一张选票如果不1的话将无法在新一轮投出选票。 2.1.7如果一个节点孤立导致leader选举一直失败任期编号不断增大则当其回到集群会影响集群吗 不会因为当其回到集群后别的节点发现自己的任期编号小于其任期编号则会更新自己的任期编号为其任期编号并且因为自己的日志完整性高于其所以也不会给其投出选票其也成不了leader所以不会有影响。 2.1.8心跳随机超时时间怎么确定如何查看 这就是属于编码实现问题了一般设置在某个时间范围内至于如何查看也是和具体程序实现有关。 2.1.9raft算法中只有leader才能接收读请求吗 raft算法本身没有要求如果是要求最终一致性则可以允许非leader读取比如zookeeper就是如此直接响应本地数据。 2.1.10如果集群正在选主此时集群还能正常工作吗 写请求无法执行需要客户端重试。读请求如果是允许非leader处理的话则正常否则也需要重试等到选主完成。 2.1.11因为leader心跳超时导致选举出新leader当老leader收到新leader心跳时会如何处理 更新自己的状态为跟随者并使用新leader的任期编号更新自己的任期编号。 3日志复制 可以认为为日志即数据日志由日志项组成且日志必须是连续的这不同于multi-paxos。一个日志项包含如下3部分内容 指令用户发送的指令如set x 10这种 任期编号创建该条日志项leader的任期编号相当于是给数据标识版本 索引值单调递增的索引编号用来标识日志项如下图 日志同步过程如下 1leader生成日志条目发送日志同步RPC消息复制日志条目到其他节点 2当超过半数的节点返回复制成功消息后将日志项应用到状态机通过状态机记录日志项已经写入成功然后返回成功消息给客户端这里需要注意leader在收到了大多数节点写入成功消息后并不会再次发送提交日志条目消息到其他节点也就是两阶段提交变为了一阶段提交这里提交的消息并不是不发了而只是会随着后续的同步日志消息或者是leader的心跳消息来同步给其他节点这样就可以减少一半的网络交互开销可通过下图对比查看 假设节点A,节点B节点C节点D,其中节点A为leader任期编号为9索引编号是88发送的指令是set x90,即要发送的日志段是(88,9set x90)则该过程如下图 源码实现参考这里 ,运行效果如下图 3.1如何实现日志一致性 如果节点一直处于正常状态节点能够正常的复制来自leader的日志段但是如果是发生了宕机重启等故障后follower出现了和leader的日志不一致这种情况raft算法是怎么实现恢复一致的呢?我们一起来看下。首先看以下的点 1数据绝对以leader的为准 2leader可以覆盖和删除follower不一致的数据 3leader的数据不会被覆盖和删除为了处理可能出现的日志一致性问题leader在发送日志同步消息时除了携带日志段外还会携带当前日志段的上一个日志段的索引号以及对应的任期编号如下要发送的索引号就是7任期编号就是4 当follower收到后会对比自己的最新的日志段是否匹配二者如果匹配的话则接受日志段否则返回失败返回失败后leader继续向前找继续发送直到follower接受则从接收的位置发送后续日志段覆盖follower的日志段从而使得和leader的日志保持一致可参考下图 3.2常见问题 3.2.1如果超过半数follower都收到日志段但是leader还未应用状态到状态机此时leader挂掉数据会丢失吗? 不会因为最终当选为新leader的node是有该未提交日志段的然后发现超过半数的node都有该日志段老leader肯定是有的所以这里的半数要包括老leader则会提交日志段并在后续发送消息给其它follower也提交该日志段。 3.2.2如何保证客户端写操作请求到leader? 一般有两种方式假定收到请求的节点是follower1follower充当代理角色转发请求给leader 2follower返回leader地址给客户端客户端再次向leader发起写请求。 4成员变更 成员变更是指通过新增节点来增加副本数成员变更的一个问题就是集群短时间内处于不稳定状态而可能会导致出现2个leader的情况这就违背了leader唯一性的原则而导致出现这个问题的原因一般都是网络分区如下是有3个节点的集群 此时集群配置是[ABC]现在加入2个节点DE如下图 假定集群稳定前的某一刻发生了网络分区AB处于一个分区CDE处于一个分区如下图 此时新配置是[A,B,C,D,E]则新配置的大多数就是3,如上图就产生了新leader C,而老配置是[A,B,C]则老配置的大多数就是2,产生了新leader A此时就出现了2个leader A 和 C这样就有问题了。raft解决这个问题的方式有联合共识和单节点变更联合共识是最初的方案但因为过于复杂所以后续就有了单节点变更的方案这种方案可以解决因为一次添加过多节点导致出现分区时同时满足新旧大多数而破坏leader唯一性的问题。接下来我们看下单节点变更的方案假设依然是3个节点ABC如下 首先添加一个节点D 此时老配置是[A,B,C]大多数是2新配置是[A,B,C,D]大多数是3只有总节点数至少为5才能同时满足新旧配置的大多数而此时节点数是4所以在出现网络分区不会满足1个leader的情况接着我们来增加节点E 此时老配置是[A,B,C,D]大多数是3,新配置是[A,B,C,D,E],大多数是3要想满足新旧配置的大多数则至少需要有6个节点而此时只有5个节点所以不管出现何种情况的分区也不可能出现1个leader的情况。 写在后面 小结 本文一起看了raft共识算法对分布式系统中leader选举日支复制成员变更3个主要问题提供的解决思路。希望本文能够帮助到你。 参考文章列表 分布式之Paxos共识算法分析 。 分布式理论之分布式选举 。 The Secret Lives of Data 。 什么是状态机一篇文章就够了 。 状态机分析 。