XA规范及2PC 3PC 介绍
XA规范及2PC 3PC 介绍
XA 规范的定位：是早期为解决分布式事务（一个系统操作多个数据库）问题制定的一套解决方案，定义了分布式事务模型。
模型中的角色：
AP（应用程序）：发起分布式事务操作的应用主体。
TM（事务管理器）：负责统筹管理整个事务流程。
RM（资源管理器）：具体资源的管理方，如数据库（示例中以 MySQL 说明）。
CRM（通信资源管理器）：处理事务过程中的通信，属于可选组件（如消息中间件）。
核心概念：全局事务
指横跨多个数据库的事务操作，要求所有参与数据库的操作具备原子性 —— 要么全部成功，若任一操作失败，则所有数据库操作全部回滚，以此保证分布式事务的一致性，避免部分成功、部分失败的不一致状态。
XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。
XA 规范偏向理论层面，落地性不足；而 2PC 是基于 XA 规范设计的分布式事务落地实现方案，属于一套具体的规范或协议。
定义与作用：2PC 全称 Two-Phase-Commitment-Protocol（两阶段提交协议），通过明确分布式事务处理的具体阶段和流程（两阶段提交过程），将 XA 规范的理论转化为可操作的实践步骤，解决分布式事务在实际应用中的落地问题，保障分布式场景下事务的一致性。
2、2PC 理论
x/open组织定义的一套分布式事务的模型，还是比较虚的，还没办法落地，而且XA接口规范也是一个比较务虚的一个东西，还是没法落地的
基本上来说，你搞明白了 XA也就明白了 2PC了，2Pc说白了就是基于 XA规范搞的一套分布式事务的理论,也可以叫做一套规范,或者是协议。
2PC（Two-Phasp-Commitment-Protocol,两阶段提交协议），其实就是基于 xA规范，来让分布式事务可以落地，定义了很多实现分布式事务过程中的一些细节
(1)准备阶段
简单来说，就是 TM 先发送个 prepare消息给各个数据库，让各个库先把分布式事务里要执行的各种操作，先准备执行，其实此时各个库会差不多先执行好，就是不提交罢了
如果你硬是要理解一下的话，也可以认为是 prepare 消息一发，各个库先在本地开个事务，然后执行好 SQL，而且注意这里各个数据库会准备好随时可以提交或者是回滚，有对应的日志记录的
然后各个数据库都返回一个响应消息给事务管理器，如果成功了就发送一个成功的消息，如果失败了就发送一个失败的消息
(2)提交阶段
第一种情况，要是 TM发现某个数据库告诉他说失败了。或者是 TM等了半天，某个数据库楞是死活不返回消息，
这个时候 TM 直接判定这个分布式事务失败，毕竟某个数据库那里抛异常了，然后 TM通知所有的数据库，全部回滚，做了啥操作都回滚，其实这里你可以认为是通知每个数据库，把自己本地的那个事务回滚不就得了，然后各个库都回滚好了以后就通知 TM，TM 就认为整个分布式事务都回滚了
但是呢，要是 TM 接收到所有的数据库返回的消息都是成功，直接发送个消息通知各个数据库说提交，然后各个数据库都在自己本地提交事务呗，就这么回事儿，提交好了通知下 TM，TM要是发现所有数据库的事务都提交成功了，就认为整个分布式事务成功了
2PC（两阶段提交协议）的核心缺陷
- 同步阻塞 ：在 2PC 第一阶段（Prepare 阶段），资源会被持续占用，直至整个分布式事务完成才释放。若此时其他操作请求访问该资源，会因资源被锁定而被迫阻塞，严重影响系统并发处理能力。
- 单点故障：事务管理器（TM）作为协调事务的核心单点角色，一旦 TM 崩溃或挂掉，整个分布式事务流程会彻底中断，无法继续推进提交或回滚操作，导致系统可用性大幅降低。
- 事务状态丢失 ：即使通过双机热备机制选举新 TM，若原 TM 挂掉时，部分资源管理器（RM）已接收 Commit 消息但未反馈，新 TM 无法获取这些 RM 的真实处理状态，最终导致事务状态丢失，无法正确完成后续操作。
- 脑裂问题（数据不一致） ：在第二阶段（Commit 阶段），若因网络等问题出现“脑裂”，部分 RM 未收到 Commit 消息，会导致数据库间状态不一致——部分数据库提交事务，部分未提交，破坏分布式事务的一致性。
3PC（三阶段提交协议）的执行流程 ：
CanCommit 阶段 ： 事务管理器（TM）向各数据库发送 CanCommit 消息，询问数据库是否准备好参与事务。数据库仅检查自身网络、资源状态等，回复是否 ready，此阶段不实际执行 SQL 操作，仅完成事务前置条件的确认。
PreCommit 阶段 ： - 若所有数据库在 CanCommit 阶段均回复成功，TM 发送 PreCommit 消息，触发数据库执行事务操作（类似 2PC 的准备阶段），但暂不提交事务。 - 若有数据库在 CanCommit 阶段回复失败，TM 发送 abort 消息，直接终止分布式事务。
DoCommit 阶段 ： - 若所有数据库在 PreCommit 阶段反馈成功，TM 发送 DoCommit 消息，数据库正式提交事务，完成分布式事务。 - 若有数据库在 PreCommit 阶段反馈失败，或超时未响应，TM 判定事务失败，发送 abort 消息，所有数据库回滚事务，回滚完成后通知 TM。 3PC 通过新增阶段和更细化的流程控制，优化了分布式事务处理的容错性，改进了 2PC 存在的部分问题。
C 通过新增阶段和更细化的流程控制，优化了分布式事务处理的容错性，改进了 2PC 存在的部分问题。
