4.1 XA 规范
X/Open的组织定义了分布式事务的模型，这里面有几个角色，AP（Application，应用程序），TM（Transaction Manager，事务管理器），RM（Resource Manager，资源管理器），CRM（Communication Resource Manager，通信资源管理器）。
全局事务：X/Open组织定义了一套分布式事务的模型和规范。一个横跨多个数据库的事务。就是一个事务里，涉及了多个数据库的操作，然后要保证多个数据库中，任何一个操作失败了，其他所有库的操作全部回滚，这就是所谓的分布式事务。
DTP（Distributed Transaction Processing Reference Model）：分布式事务处理模型。TM、RM、AP等角色的分布式事务的模型。
JTA事务：Java Transaction API，分布式事务的编程API，它是按照XA、DTP那套模型和规范来搞的，在J2EE中，单库的事务是通过JDBC事务来支持的，如果是跨多个库的事务，是通过JTA API来支持的，通过JTA API可以协调和管理横跨多个数据库的分布式事务，一般来说会结合JNDI。
4.2 2PC协议
2PC，Two-Phase Commit，即二阶段提交，二阶段提交协议是将事务的提交过程分成了两个阶段来进行处理。
MySQL支持的是2PC协议。
2PC协议的缺陷：
1、同步阻塞：在阶段一里执行prepare操作会占用资源，一直到整个分布式事务完成，才会释放资源，这个过程中，如果有其他人要访问这个资源，就会被阻塞住。
2、单点故障：TM是个单点。
3、事务状态丢失：即使把TM做成一个双机热备的，一个TM挂了自动选举其他的TM出来，但是如果TM挂掉的同时，接收到commit消息的某个库也挂了，此时即使重新选举了其他的TM，根本不知道这个分布式事务当前的状态，因为不知道哪个库接收过commit消息，哪个接收过commit消息的库也挂了。
4、脑裂问题：在阶段二中，如果发生了脑裂问题，那么就会导致某些数据库没有接收到commit消息，有些库收到了commit消息。
4.3 3PC协议
3PC，Three-Phase Commit，即三阶段提交，是2PC的改进版，其将二阶段提交协议的"提交事务请求"过程一分为二，形成了CanCommit、PreCommit和do Commit三个阶段组成的事务处理协议。
3PC协议的缺陷：
如果TM在DoCommit阶段发送了abort消息给各个库，结果因为脑裂问题，某个库没接收到abort消息，自己还去进行commit操作，导致数据出错。
4.4 JTA + Atomikos
XA分布式事务：管理横跨多个数据库的分布式事务。一般用于单系统多库的场景，要是多系统多库，比较麻烦。
JTA负责Atomikos框架的一个指挥和调度，让它按照事务的基本步骤来走，Atomikos框架相当于是DTP模型里的TM，跟各个MySQL（RM）通信，XA START、XA END、XA COMMIT、XA ROLLBACK等符合XA规范的一套接口调用。
实现原理：创建分布式事务的时候，创建一个代表了分布式事务的对象。在各个SQL执行的时候，必须从 自定义的DataSource里面获取Connection，对Connection的prepareStatement()方法的调用，需要进行拦截，去对各个库执行XA START指令，以及定义好SQL；在提交事务的时候，需要去对各个库执行XA PREPARE指令，如果都成功，就执行XA COMMIT指令，如果失败，就执行XA ROLLBACK指令。
