大规模共识算法：第7部分 - 请求传播
内容提要
本文讨论了领导变更期间请求传播的共识算法，重点在于处理请求的持久性和失败情况。通过版本控制和反抖动规则，确保系统在领导变更时有效管理请求，避免冲突和不完整请求的影响。以MySQL和Vitess为例，展示了如何通过元数据传播解决事务冲突。
延伸解读
领导变更时请求传播的难点
文章指出，领导变更时需要将已完成的请求传播给新领导，以满足其持久性要求。但故障场景下，可能存在不完整请求、无法确定请求是否持久、传播过程中失败等复杂情况。选举者可能无法发现所有不完整请求，导致后续选举者面对多个冲突请求时难以抉择。这些难点使得请求传播成为共识算法中最困难的部分。
版本控制与反抖动规则的作用
为解决上述难点，文章提出为每个请求分配基于时间的版本，领导者用更新的版本创建请求，选举者传播不完整请求时也使用新版本。这样，当发现多个冲突请求时，可安全选择最新版本，因为旧请求肯定未完成。此外，反抖动规则能防止领导权频繁变更，并缓解故障模式，使版本控制的重要性降低。
MySQL与Vitess的实践
MySQL的binlog包含全局事务ID和时间戳，能解决故障导致的冲突事务歧义。但忠实传播元数据违反了新选举者决策需用新时间戳的版本规则。Orchestrator内置反抖动规则，缓解了这一问题，使MySQL能大规模运行而不出现脑裂。Vitess的VTorc继承了这些安全性，并计划进一步减少复杂故障时的人工干预。
Q&A
在领导变更期间，如何确保请求的持久性？
通过传播已完成的请求来满足新领导的持久性要求。
什么是反抖动规则，它在请求传播中有什么作用？
反抖动规则防止领导频繁变更，确保系统稳定性，避免加剧潜在问题。
MySQL的binlogs在处理事务冲突时有什么作用？
MySQL的binlogs包含所有事务的元数据，能够解决由于失败导致的冲突事务的模糊性。
在请求传播中，选举者需要满足什么条件？
选举者必须能够联系到足够数量的跟随者以撤销之前的领导，否则将被阻塞。
如何处理请求传播中的失败情况？
选举者需要请求跟随者停止接受来自前领导的请求，以确保撤销成功。
Vitess如何改进请求传播的安全性？
Vitess使用VTorc，继承了MySQL的安全性，并计划减少复杂故障时对人工干预的需求。
