2PC方案
概念
2PC全称两阶段提交协议。分布式系统中用于保证原子性的算法
核心目标：确保一个涉及多个独立节点的分布式事务，要么全部成功（所有节点全部提交），要么全部失败（所有节点全部回滚）。它不允许出现部分节点成功，部分节点失败的状态。
核心角色
在一个2PC事务中，通常包含两个角色：
协调者：只有一个。负责统一管理整个分布式事务的流程，驱动参与者进行提交或者回滚。通常由应用程序、中间件、数据库担任。
参与者：有多个。每个参与者负责管理自身数据操作（本地事务），并根据协调者的指令执行最终的提交或者回滚。
协议的两个阶段
第一阶段：投票阶段
这个阶段的目的是“询问”所有参与者是否准备好提交。
1.1协调者向所有参与者发送PREPARE请求（或称VOTE_REQUEST）,其中包含需要执行的事务信息。
1.2每个参与者收到请求后，会执行本地事务的所有操作（但不提交），将undo和redo信息写入日志（为了故障恢复）。
1.3参与者根据自身情况，向协调者投票：
如果本地事务执行成功，参与者回复YES（或AGREEMENT），表示已准备好提交。
如果本地事务执行失败（如违反约束，网络中断等），参与者回复NO（或ABORT）。
关键点：参与者在回复YES后，就进入了一种“不确定状态”。它已经承诺会服从协调者的最终指令（提交或者回滚），在收到最终指令前，它必须锁定其持有的相关资源，阻止其他事物访问。这是2PC的一个主要缺点。
第二阶段：提交回滚阶段
这个阶段的目的是根据第一阶段的投票下达最终指令。协调者收集所有参与者的投票情况：
情况一：所有参与者都回复YES
1.1协调者决定提交事务
1.2协调者向所有参与者发送COMMIT请求
1.3参与者收到COMMIT请求后，正式提交其本地事务，释放持有的锁和资源
1.4参与者完成提交后，向协调者发送ACK确认消息
1.5协调者收到所有参与者的ACK消息后，整个分布式事务完成
情况二：任何一个或者多个参与者回复NO或者超时未响应
1.1协调者决定回滚事务
1.2协调者向所有参与者发送ROLLBACK请求
1.3参与者收到ROLLBACK请求后，利用之前写入的undo日志回滚其本地事务，释放持有的锁和资源
1.4参与者完成提交后，向协调者发送ACK确认消息
1.5协调者收到所有参与者的ACK消息后，整个分布式事务终止
优缺点
优点
1.1严格保证了分布式事务的原子性
缺点
1.1同步阻塞：最大的问题。在参与者投票 YES 后，到收到协调者最终指令之前，它持有的资源锁一直被占用。在此期间，其他访问这些资源的事务必须等待。如果协调者宕机，这些锁将一直被持有，导致整个系统“卡住”。
1.2单点故障：协调者角色至关重要。一旦协调者在发送 PREPARE 之后宕机，所有参与者将一直处于“不确定”状态，无法知道最终应该提交还是回滚，导致资源被无限期锁定。
1.3数据不一致：在第二阶段，如果协调者只发送了部分 COMMIT 消息后就宕机了，那么只有部分参与者提交了事务，而其他参与者没有，导致数据不一致。尽管可以通过日志和重试机制来弥补，但在理论上仍存在不一致的窗口期。