大规模共识算法：第六部分 - 完成请求
内容提要
共识算法的第六部分讨论了请求的完成。共识系统必须确保已确认的请求不会被遗忘，采用两阶段协议来满足这一要求。请求经历不完整、持久和完成三个阶段。完成与取消是互斥的，收到完成消息后，跟随者可以执行请求的效果。MySQL的半同步协议不支持这种两阶段方法，可能导致问题。
延伸解读
两阶段协议的核心机制
文章提出用两阶段协议确保已确认请求不被遗忘。领导者先将请求作为暂定请求发送给所有节点，跟随者确认收到后，请求达到持久阶段，此时不可取消。随后领导者发送完成消息，跟随者执行请求效果。这种设计将请求生命周期明确划分为不完整、持久和完成三个阶段，使系统在故障时能清晰判断请求状态，避免误取消已持久化的请求。
完成与取消的互斥性
完成和取消是互斥操作：已完成的请求永远不会被取消，已取消的请求也永远不会被完成。跟随者收到完成消息后，可以执行请求的效果，例如修改变量值；收到取消消息后，则删除请求，如同从未发生。这种互斥性保证了请求状态的一致性，防止因消息乱序或重复导致的数据不一致问题。
响应时机的权衡
领导者可以在请求持久化后立即向客户端返回成功，也可以延迟到向跟随者发送完成消息后再响应。延迟响应需要两个往返，速度较慢，但能提升仲裁读的性能。对于使用基于锁的故障转移的系统，读可以发送给当前领导者，从而允许领导者收到必要确认后立即响应。这一权衡取决于系统采用的读策略。
MySQL半同步协议的局限
MySQL的半同步协议不支持两阶段完成请求的方法。副本收到请求后立即应用，这引入了需要缓解的边界情况。此外，主库在崩溃重启后会完成所有进行中的请求，而不验证它们是否获得了必要的确认，这可能导致“分脑”场景。这些行为与共识系统要求的持久化保证存在冲突，需要额外处理。
Q&A
共识系统如何确保已确认的请求不会被遗忘？
共识系统通过引入两阶段协议，确保已确认的请求不会被遗忘，首先将请求作为暂定请求传输给所有节点。
请求在共识系统中经历哪些阶段？
请求经历不完整、持久和完成三个阶段。
完成与取消请求之间有什么关系？
完成与取消是互斥的，已完成的请求不会被取消，已取消的请求也不会被完成。
MySQL的半同步协议在请求完成方面存在哪些问题？
MySQL的半同步协议不支持两阶段方法，可能导致在未确认的情况下完成请求，从而引发“分脑”场景。
在共识系统中，如何处理请求的完成和取消？
收到完成消息后，跟随者可以执行请求的效果；收到取消消息后，跟随者可以删除请求。
共识系统中，领导者如何确保请求的持久性？
领导者通过向足够多的节点传输请求并获得确认来确保请求的持久性。
