3PC(三阶段提交)

本文主要是介绍3PC(三阶段提交)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

三阶段提交

3PC（Three-Phase Commit）是一种分布式系统中用于实现事务一致性的协议，它是在2PC（Two-Phase Commit）的基础上发展而来，旨在解决2PC的一些缺点。与2PC的两个阶段（准备和提交）相比，3PC引入了一个额外的阶段，即预提交阶段。

三个阶段

以下是3PC的三个阶段：

1. CanCommit（准备阶段）：
   • 在这个阶段，协调者向所有的事务参与者询问是否可以提交事务。每个参与者要么发送“同意”消息，表示可以提交，要么发送“中止”消息，表示不能提交。
2. PreCommit（预提交阶段）：
   • 如果所有的参与者都发送了“同意”消息，协调者将向所有的参与者发送“预提交”消息，通知它们准备提交事务。参与者会在本地执行预提交操作，但是还不会真正提交。
3. DoCommit（提交阶段）：
   • 如果在预提交阶段没有发生错误，协调者将向所有的参与者发送“提交”消息，要求它们最终提交事务。如果有任何参与者在预提交阶段发生了错误，协调者将发送“中止”消息，要求所有的参与者回滚事务。

为什么引入3PC?

引入3PC的主要目的是为了解决2PC的阻塞问题。在2PC中，如果在准备阶段有一个参与者不能提交，整个系统就会被阻塞，无法继续事务的提交。3PC通过引入预提交阶段，使得即使在准备阶段有参与者不能提交，系统仍然能够继续前进，提高了系统的可用性和容错性。尽管3PC并不能完全解决所有的分布式系统问题，但相对于2PC来说，它是一种更为灵活和容忍性更强的协议。

和2PC的区别

1. 阶数不同：2PC有两个阶段，准备阶段和提交阶段；而3PC引入了额外的预提交阶段，协议包括准备阶段、预提交阶段和提交阶段。
2. 阻塞问题：2PC存在阻塞问题，即在准备阶段有任何参与者不能提交，那么整个系统可能被阻塞；3PC通过引入预提交阶段尝试解决整个问题，在与提交阶段，协调者通知参与者可以准备提交，但尚未真正提交，从而在出现问题时能够更好的处理。
3. 协议设计：2PC是一种悲观锁协议，一旦准备开始，就要所有节点都能提交；而3PC更加乐观，在CanCommit阶段，只是询问参与者是否可以提交，但并未要求确保一定会提交。
4. 一致性级别：2PC要求强一致性，要么全部提交，要么全部回滚；3PC也最求强一致性，但更具容忍性。

3PC存在的问题

1. 阻塞问题的根本为解决：通过预提交阶段减轻了一些阻塞问题，但是在网络分区或者节点故障的情况下，仍然可能导致无法得知参与者状态，无法继续事务的提交。
2. 性能开销：引入了与提交，可能带来性能上的开销。
3. 复杂性：引入预提交，增加了协议的复杂性，在实现和维护上相对于其他协议可能更加复杂。

CanCommit阶段返回“同意”后发生故障，系统该如何处理？

超时和重试： 协调者可以设置一个超时时间，在等待参与者的响应时启动。如果超过超时时间仍未收到参与者的确认，可以选择进行重试。这样可以尽量处理一些短暂的故障。

等待参与者恢复： 如果参与者发生故障，系统可以等待参与者自行恢复。一旦参与者恢复，可以重新尝试进行CanCommit阶段。

中止事务： 如果参与者在CanCommit阶段返回“同意”后发生故障，系统可以选择中止整个事务。协调者向所有参与者发送“中止”消息，要求它们回滚事务。这确保了事务的一致性，但可能会引入一些性能开销和数据的不一致性。

补偿性操作： 如果系统允许，可以设计一些补偿性操作，用于处理在CanCommit阶段后参与者发生故障的情况。通过执行适当的补偿性操作，可以尽量还原到一个一致的状态。

日志和持久化： 在CanCommit阶段执行本地操作之前，参与者可以将CanCommit阶段的信息持久化到本地日志中。即使参与者在CanCommit阶段后发生故障，通过日志信息，系统可以在参与者恢复后进行一些补救性操作。

人工介入： 在一些特殊情况下，可能需要人工介入来处理CanCommit阶段后参与者发生故障的问题。这可能包括系统管理员的手动操作，以确保系统的一致性和正常运行。

这篇关于3PC(三阶段提交)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---