XA模型和2PC协议
XA模型或者X/Open DTP模型
X/OPEN是一个组织.X/Open国际联盟有限公司是一个欧洲基金会，它的建立是为了向UNIX环境提供标准。它主要的目标是促进对UNIX语言、接口、网络和应用的开放式系统协议的制定。它还促进在不同的UNIX环境之间的应用程序的互操作性，以及支持对电气电子工程师协会（IEEE）对UNIX的可移植操作系统接口（POSIX）规范
X/Open DTP(Distributed Transaction Process) 是一个分布式事务模型。这个模型主要使用了两段提交(2PC - Two-Phase-Commit)来保证分布式事务的完整性。
在X/Open DTP(Distributed Transaction Process)模型里面，有三个角色：
AP: Application，应用程序。也就是业务层。哪些操作属于一个事务，就是AP定义的。
TM: Transaction Manager，事务管理器。接收AP的事务请求，对全局事务进行管理，管理事务分支状态，协调RM的处理，通知RM哪些操作属于哪些全局事务以及事务分支等等。这个也是整个事务调度模型的核心部分。
RM：Resource Manager，资源管理器。一般是数据库，也可以是其他的资源管理器，如消息队列(如JMS数据源)，文件系统等。
XA把参与事务的角色分成AP，RM，TM。
AP，即应用，也就是我们的业务服务。
RM指的是资源管理器，即DB，MQ等。
TM则是事务管理器。
AP自己操作TM，当需要事务时，AP向TM请求发起事务，TM负责整个事务的提交，回滚等。
XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。
XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲（参考Fischer等的论文），两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源（如数据库或JMS队列）
2PC（标准XA模型）
2PC即Two-Phase Commit，二阶段提交。
2PC节点角色
二阶段提交协议将节点分为：
- 协调者角色(事务管理器Coordinator)
- 参与者角色（资源管理器Participant）
2PC角色中，事务管理器的角色，负责协调多个数据库（资源管理器）的事务，
协调者角色(事务管理器Coordinator)，负责向参与者发送指令，收集参与者反馈，做出提交或者回滚决策
参与者角色（资源管理器Participant），接收协调者的指令执行事务操作，向协调者反馈操作结果，并继续执行协调者发送的最终指令
详解：二个阶段
广泛应用在数据库领域，为了使得基于分布式架构的所有节点可以在进行事务处理时能够保持原子性和一致性。
顾名思义，2PC分为两个阶段处理，
- 阶段一：提交事务请求、
- 阶段二：执行事务提交，或者执行中断事务;
如果阶段一超时或者出现异常，2PC的阶段二为：执行中断事务
说明：绝大部分关系型数据库，都是基于2PC完成分布式的事务处理。
阶段一：提交事务请求
- 事务询问。协调者向所有参与者发送事务内容，询问是否可以执行提交操作，并开始等待各参与者进行响应；
- 执行事务。各参与者节点，执行事务操作，并将Undo和Redo操作计入本机事务日志；
- 各参与者向协调者反馈事务问询的响应。成功执行返回Yes，否则返回No。
阶段二：执行事务提交，或者执行中断事务;
这一阶段包含两种情形：
- 执行事务提交，
- 执行中断事务
协调者在阶段二决定是否最终执行事务提交操作。
- 所有参与者reply Yes，那么执行事务提交。
- 当存在某一参与者向协调者发送No响应，或者等待超时。协调者只要无法收到所有参与者的Yes响应，就会中断事务。
执行事务提交
所有参与者reply Yes，那么执行事务提交。
- 发送提交请求。协调者向所有参与者发送Commit请求；
- 事务提交。参与者收到Commit请求后，会正式执行事务提交操作，并在完成提交操作之后，释放在整个事务执行期间占用的资源；
- 反馈事务提交结果。参与者在完成事务提交后，向协调者发送Ack消息确认；
- 完成事务。协调者在收到所有参与者的Ack后，完成事务。
执行事务中断
事情总会出现意外，当存在某一参与者向协调者发送No响应，或者等待超时。协调者只要无法收到所有参与者的Yes响应，就会中断事务。
- 发送回滚请求。协调者向所有参与者发送Rollback请求；
- 回滚。参与者收到请求后，利用本机Undo信息，执行Rollback操作。并在回滚结束后释放该事务所占用的系统资源；
- 反馈回滚结果。参与者在完成回滚操作后，向协调者发送Ack消息；
- 中断事务。协调者收到所有参与者的回滚Ack消息后，完成事务中断。
2pc解决的是分布式数据强一致性的问题
顾名思义，两阶段提交在处理分布式事务时分为两个阶段：voting（投票阶段，有的地方会叫做prepare阶段）和commit阶段。
2pc中存在两个角色，事务协调者（如 seata、atomikos、lcn）和事务参与者，其中，事务参与者通常是指应用的数据库
2pc二阶段提交的特点
2PC 方案比较适合单体应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。
2PC 方案实际很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。
现在的微服务系统，一个大的系统分成几百个服务，几十个服务。一般来说，我们的规定和规范，是要求每个服务只能操作自己对应的一个数据库。
如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范，你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，没法治理的，可能会出现数据被别人改错，自己的库被别人写挂等情况。
如果你要操作别人的服务的库，你必须是通过调用别的服务的接口来实现，绝对不允许交叉访问别人的数据库。
2PC具有明显的优缺点：
优点:
- 主要体现在实现原理简单；
缺点比较多：
- 同步阻塞导致性能问题
执行过程中，所有参与节点都是事务阻塞型的。
所有participant 都处于阻塞状态，各个participant 都在等待其他参与者响应，无法进行其他操作。
所有分支的资源锁定时间，由最长的分支事务决定。
另外当参与者锁定公共资源时，处于事务之外的其他第三方访问者，也不得不处于阻塞状态。
- 单点故障导致高可用（HA）问题：
协调者是个单点，一旦出现问题，各个participant 将无法释放事务资源，也无法完成事务操作；
并且，由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞下去。
尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。
假设，协调者挂掉，可以重新选举一个协调者，但是，还是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题。
- 丢失消息导致的数据不一致问题：
如果协调者向所有参与者发送Commit请求后，发生局部网络异常,
或者协调者在尚未给全部的participant发送完Commit请求即出现崩溃，最终导致只有部分participant收到、执行请求。
于是整个系统将会出现数据不一致的情形，why？
只有一部分参与者接受到了commit请求。
部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
- 过于保守：
二阶段提交协议没有设计较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。
具体来说：
2PC没有完善的容错机制，当参与者出现故障时，协调者无法快速得知这一失败，只能严格依赖超时设置来决定是否进一步的执行提交还是中断事务。
