自己搞个网站,自己在家怎么做电商,WordPress代码查看,莆田有哪几家做网站设计的简介#xff1a; Raft提出的两阶段成员变更Joint Consensus是业界主流的成员变更方法#xff0c;极大的推动了成员变更的工程应用。但Joint Consensus成员变更采用两阶段#xff0c;一次变更需要提议两条日志#xff0c; 在一些系统中直接使用时有些不便。那么Joint Consen…简介 Raft提出的两阶段成员变更Joint Consensus是业界主流的成员变更方法极大的推动了成员变更的工程应用。但Joint Consensus成员变更采用两阶段一次变更需要提议两条日志 在一些系统中直接使用时有些不便。那么Joint Consensus成员变更能否只使用单步实现呢 作者 | 祥光 来源 | 阿里技术公众号
一 引言
分布式系统运行过程中节点经常会出现故障需要支持节点的动态增加、删除和替换。 成员变更是分布式系统绕不开的话题特别是在一致性系统中对于提升运维能力和服务可用性都有很大的帮助。
Raft提出的两阶段成员变更Joint Consensus是业界主流的成员变更方法极大的推动了成员变更的工程应用。但Joint Consensus成员变更采用两阶段一次变更需要提议两条日志 在一些系统中直接使用时有些不便。虽然Raft也提出了单步成员变更方法但单步成员变更方法一次只能增加或减少一个成员限制较大并且容易踩坑一般不推荐使用。
那么很自然的想到Joint Consensus成员变更能否只使用单步实现呢本文对这个问题进行了深入探讨。
二 成员变更
我们先来回顾下一致性协议中的成员变更问题。成员变更是在集群运行过程中改变运行一致性协议的节点如增加、减少节点、节点替换等。成员变更过程不能影响系统的可用性。
成员变更也是一个一致性问题即所有节点对成员配置达成一致。但是成员变更又有其特殊性因为在成员变更的过程中参与投票的成员会发生变化。 图1 成员变更的某一时刻Cold和Cnew中同时存在两个不相交的多数派
如果将成员变更当成一般的一致性问题成员变更过程中各节点从旧成员配置Cold切换到新成员配置Cnew的时刻可能有差异可能在某一时刻Cold和Cnew中同时存在两个不相交的多数派形成双Quorum破坏一致性。
为了解决这个问题Raft提出了两阶段的成员变更方法Joint Consensus。
1 Joint Consensus成员变更
Joint Consensus成员变更为了避免双Quorum问题引入一个联合成员配置Cold,new作为过渡配置 Cold,new是Cold和Cnew的组合。Cold与Cold,new的Quorum有交集Cold,new与Cnew的Quorum也有交集。成员变更先从Cold切换到Cold,new待Cold,new提交后再切换到Cnew保证Cold与Cnew不同时使用因而不会形成双Quorum保障安全性。 图2 Cold与Cold, new与Cnew三者的Quorum集合之间的关系
Joint Consensus使用两条日志完成成员变更过程。Leader收到成员变更请求后先向Cold和Cnew同步一条Cold,new日志此后所有日志都需要Cold和Cnew两个多数派的确认。Cold,new日志在Cold和Cnew都达成多数派之后才能提交此后Leader再向Cold和Cnew同步一条只包含Cnew的日志此后日志只需要Cnew的多数派确认。Cnew日志只需要在Cnew达成多数派即可提交此时成员变更完成不在Cnew中的成员自动下线。 图3 Joint Consensus成员变更过程
成员变更过程中如果发生Failover老Leader宕机Cold,new中任意节点都可能成为新Leader如果新Leader上没有Cold,new日志则继续使用ColdFollower上如果有Cold,new日志会被新Leader截断回退到Cold成员变更失败如果新Leader上有Cold,new日志则继续将未完成的成员变更流程走完。
2 单步成员变更
Joint Consensus成员变更之所以需要两个阶段是因为对Cold与Cnew的关系没有做任何假设为了避免Cold和Cnew各自形成不相交的多数派而形成双Quorum才引入了两阶段方案。
如果增强成员变更的限制假设Cold与Cnew的Quorum交集不为空Cold与Cnew就无法形成双Quorum则成员变更就可以简化为一阶段。
实现单步的成员变更关键在于限制Cold与Cnew使Cold与Cnew的Quorum交集不为空。那么怎么样限制Cold与Cnew才能使Cold与Cnew的Quorum交集不为空呢方法就是每次成员变更只允许增加或删除一个成员。 图4 增加或删除一个成员时Cold与Cnew的Quorum
增加或删除一个成员时的情形如图4所示可以从数学上严格证明只要每次只允许增加或删除一个成员Cold与Cnew不可能形成两个不相交的Quorum。因此只要每次只增加或删除一个成员从Cold可直接切换到Cnew无需过渡成员配置实现单步成员变更。
单步成员变更一次只能变更一个成员如果需要变更多个成员如实现替换成员等可以通过执行多次单步成员变更来实现。
单步成员变更理论虽然简单但却埋了很多坑实际用起来并不是那么简单。先前的文章Raft成员变更的工程实践中有详细介绍。
三 两阶段成员变更的单步实现
Joint Consensus成员变更虽然通用但是采用两阶段一次变更需要提交两条日志单步成员变更虽然只需要提交一条日志但是限制较大一次只能变更一个成员。两者的优势能否结合呢Joint Consensus成员变更能否只用单步实现呢
Joint Consensus成员变更过程中Cold,new日志的提交已经让各节点对Cnew配置达成了一致那么Cnew日志有什么作用呢能否在Cold,new日志提交后就从Cold,new配置切换到Cnew配置呢这样是不是就可以不需要Cnew日志变成单步实现了呢
考虑Joint Consensus成员变更中Cnew日志的作用Cnew日志在Cold,new日志提交之后发起提议节点收到并持久化Cnew日志后从Cold,new配置切换到Cnew配置不在Cnew配置中的成员在Cnew日志提交后下线。根据这个过程可以总结出Cnew日志的作用
通知节点在收到并持久化Cnew日志后从Cold,new配置切换到Cnew配置。通知不在Cnew配置中的节点在Cnew日志提交后下线。成员变更过程中发生Failover后本地有Cnew日志的节点具有优先选举权。
如果能不使用Cnew日志同时又完成Cnew日志的工作不就可以用单步实现两阶段的Joint Consensus成员变更吗事实上已经有系统探索过这条路。
1 ZooKeeper成员变更
ZooKeeper从3.5.0版本开始在Zab的基础上支持了成员变更。ZooKeeper具有Primary Order特性而使用两条日志的Joint Consensus成员变更无法保证Primary Order特性为了既满足成员变更的通用性又不丧失Primary Order特性ZooKeeper在论文《Dynamic Reconfiguration of Primary/Backup Clusters》中提出了自己的成员变更方法并在ZooKeeper中应用了此方法比Raft的提出还早。
如图5是ZooKeeper成员变更协议图中旧成员配置用S表示新成员配置用S‘表示P为Leader节点图5展示了将B1和B2节点替换成B3和B4节点的过程 图5 ZooKeeper成员变更协议
初始化为了让新节点追上最新数据新成员配置S’中的新节点B3、B4先连接到当前的主节点PP会向它们传输自己当前的状态作为他们的初始状态。在Zab协议中当备节点连接上主节点时这样的状态传输就会自动发生并且会继续从主节点P接收所有后续的操作日志例如图中的Op1和Op2这个过程中节点B3、B4不参与投票。
步骤1主节点P向连接到它的所有备节点S U S‘发送成员变更日志COPCOP日志中携带旧成员配置S和新成员配置S‘并等待旧成员配置S中的节点确认。一旦S中的多数派确认了COP日志就对S’达成了共识。
步骤2在COP日志之前的日志只需要旧成员配置S中的多数派确认可以在旧成员配置和新成员配置S U S‘中提交在COP命令之后且在S’的激活消息ACTIVATE之前的日志需要新旧成员配置S U S‘两个多数派确认并且只能在S’中提交在S’的激活消息ACTIVATE后的日志只需要在S‘中确认和提交。
步骤3主节点P等待COP日志以及S中COP之前的日志的确认。
步骤4一旦新旧成员配置S U S1两个多数派都确认了COP日志主节点P就提交COP日志并广播一条激活消息ACTIVATE来激活新成员配置S’从而完成成员变更。与日志同步消息类似ACTIVATE消息包含主节点P的Epoch携带过时的Epoch的ACTIVATE消息将被忽略。
成员变更过程中如果发生Failover可能出现下面几种情况
如果在COP日志发送之前Failover那么成员变更失败在旧成员配置中重新选主后继续工作
如果在COP日志发送之后并且在ACTIVATE之前Failover新旧成员配置中任意节点都可能成为新Leader如果新Leader上没有COP日志则成员变更失败如果新Leader上有COP日志则继续将未完成的成员变更流程走完。
如果在ACTIVATE后Failover成员变更已经完成但还无法保证新Leader一定在新成员配置中此时不在新成员配置中的节点还不能下线。因此在发送ACTIVATE消息后还需要在新成员配置中提交一条no-op日志no-op日志提交后可保证新Leader一定在新成员配置中不在新成员配置中的节点可以安全下线。
ZooKeeper利用异步的Commit消息也即ACTIVATE消息来通知节点从新旧成员配置切换到新成员配置。使用异步的no-op日志让不在新成员配置中的节点安全下线。ZooKeeper的ACTIVATE消息和异步的no-op日志起到了Joint Consensus成员变更中Cnew日志的作用。
2 改进的单步实现
ZooKeeper成员变更协议不如Joint Consensus成员变更那么简洁Joint Consensus成员变更通过两阶段可以利用协议本身而不需要做过多的限制来保证成员变更的安全性。那么ZooKeeper成员变更协议是否可以改进呢
ZooKeeper成员变更协议中异步的ACTIVATE消息和no-op日志其实就是为了完成Joint Consensus成员变更中Cnew日志的作用明白了这一点后那么也可以将Joint Consensus成员变更的Cnew日志改为异步的在Cold,new日志提交后就认为成员变更完成然后异步的提交Cnew日志。之所以可以将Cnew日志改为异步的在Cold,new日志提交后就认为成员变更完成是因为Cold,new日志一旦提交各节点已经对新成员配置达成了一致再也不会回退到旧成员配置了剩下的过程最终一定会执行完成Cnew日志最终一定会提交。
还有一种改进方法是继续保留ACTIVATE消息但不使用no-op日志那么怎么样保证切换到新成员配置的节点具有优先选举权呢根据选举的安全性具有最新日志的节点具有优先选举权那么可以在选举的时候携带节点当前的成员配置在日志一样新的情况下优先给已经切换到新成员配置的节点投票即可保证切换到新成员配置的节点具有优先选举权。新成员配置中的大多数节点切换到新成员配置后不在新成员配置中的节点可以安全下线。
四 总结
Joint Consensus成员变更的提出极大的推动了成员变更的工程应用其简洁优美并且通用但是采用两阶段一次变更需要提交两条日志。本文探讨了两阶段的Joint Consensus成员变更的单步实现方法并做了一些改进为成员变更的工程应用提供了更多的选择。
原文链接 本文为阿里云原创内容未经允许不得转载。
