大规模共识算法：第四部分 - 领导的建立与撤销
内容提要
本文讨论了共识算法中的领导选举过程，强调领导的建立与撤销必须在建立新领导之前进行，以避免多个领导的情况。传统算法如Paxos和Raft在处理这些操作时过于复杂，提出了分离这些操作的必要性。通过提案编号或数据库复制等方法，可以有效实现领导的建立与撤销，并探讨了在软件更新和节点故障情况下的领导变更策略。
延伸解读
撤销与建立：顺序不可颠倒
文章强调，在共识算法中，撤销旧领导必须先于建立新领导，否则会出现多个领导。传统多数派算法如Paxos和Raft通过原子操作隐式完成撤销，但作者认为将撤销作为独立步骤更灵活，尤其适用于非多数派系统。这一分离有助于降低复杂度，并允许不同算法互换。
撤销的多种实现方式
撤销领导可以通过提案编号、数据库复制或直接降级当前领导来实现。提案编号方式中，新候选人推送新编号即可撤销旧领导；在MySQL中，通过半同步副本的复制指向变化也能达到同样效果。直接降级适用于计划内变更，如软件更新，而紧急情况则需请求跟随者停止接受旧领导请求。
计划内与紧急领导变更的权衡
文章以Vitess为例，说明计划内变更使用PRS优雅降级领导，允许完成进行中请求并缓冲新请求，避免应用错误；紧急情况如节点故障则使用ERS，强制撤销。由于软件发布频繁而节点故障较少，优化常见场景意味着优先保证计划内变更的平滑性。
算法互换性与撤销条件
只要满足撤销和建立领导的条件，不同算法可以互换。例如，一个算法通过使条件A为假来撤销，另一个通过使条件B为假，两者都有效。撤销完成后，新领导需使条件A和B为真，后续轮次可任意选择撤销方法。这体现了共识算法设计的灵活性。
Q&A
领导选举过程在共识算法中有什么重要性？
领导选举过程是共识算法中较复杂但使用较少的部分，确保系统中只有一个领导者。
如何有效地建立和撤销领导？
可以通过提案编号或数据库复制等方法有效实现领导的建立与撤销。
在什么情况下需要直接降级当前领导？
直接降级当前领导适用于计划内的变更，如软件更新。
传统算法在处理领导变更时存在哪些复杂性？
传统算法如Paxos和Raft在处理领导的建立与撤销时过于复杂，难以进行灵活修改。
在节点故障情况下，如何处理领导变更？
在节点故障情况下，需要请求跟随者停止接受当前领导的请求以实现撤销。
不同算法之间的领导建立与撤销是否可以互换？
是的，只要满足撤销和建立领导的条件，不同算法可以互换。
