上一讲演示的过程中，如果一个系统操作多个数据库，肯定是有跨多个库的分布式事务的一个问题，在很多年之前全世界，老美早就已经发现这个问题了，很早以前就定义了一整套的解决方案来处理分布式事务的问题
有个叫做X/Open的组织定义了分布式事务的模型，这里面有几个角色，就是AP（Application，应用程序），TM（Transaction Manager，事务管理器），RM（Resource Manager，资源管理器），CRM（Communication Resource Manager，通信资源管理器）
这么说有点儿抽象，其实Application说白了就是我们的系统，TM的话就是一个在系统里嵌入的一个专门管理横跨多个数据库的事务的一个组件，RM的话说白了就是数据库（比如MySQL），CRM可以是消息中间件（但是也可以不用这个东西）
然后这里定义了一个很重要的概念，就是全局事务，这个玩意儿说白了就是一个横跨多个数据库的事务，就是一个事务里，涉及了多个数据库的操作，然后要保证多个数据库中，任何一个操作失败了，其他所有库的操作全部回滚，这就是所谓的分布式事务
上面这套东西就是所谓的X/Open组织搞的一个分布式事务的模型，那么XA是啥呢？说白了，就是定义好的那个TM与RM之间的接口规范，就是管理分布式事务的那个组件跟各个数据库之间通信的一个接口，说白了就是这个意思
完了比如管理分布式事务的组件，TM就会根据XA定义的接口规范，刷刷刷跟各个数据库通信和交互，告诉大家说，各位数据库同学一起来回滚一下，或者是一起来提交个事务把，大概这个意思
这个XA仅仅是个规范，具体的实现是数据库产商来提供的，比如说MySQL就会提供XA规范的接口函数和类库实现，等等
X/Open组织定义的一套分布式事务的模型，还是比较虚的，还没办法落地，而且XA接口规范也是一个比较务虚的一个东西，光靠我说的这些东西还是没法落地的
基本上来说，你搞明白了XA也就明白了2PC了，2PC说白了就是基于XA规范搞的一套分布式事务的理论，也可以叫做一套规范，或者是协议，都ok。Two-Phase-Commitment-Protocol，两阶段提交协议
2PC，其实就是基于XA规范，来让分布式事务可以落地，定义了很多实现分布式事务过程中的一些细节
（1）准备阶段
画个图来玩玩儿，用咱们的那个流量充值的例子来举个例子好了，简单来说，就是TM先发送个prepare消息给各个数据库，让各个库先把分布式事务里要执行的各种操作，先准备执行，其实此时各个库会差不多先执行好，就是不提交罢了
如果你硬是要理解一下的话，也可以认为是prepare消息一发，各个库先在本地开个事务，然后执行好SQL，万事俱备只欠东风了，而且注意这里各个数据库会准备好随时可以提交或者是回滚，有对应的日志记录的
然后各个数据库都返回一个响应消息给事务管理器，如果成功了就发送一个成功的消息，如果失败了就发送一个失败的消息
（2）提交阶段
第一种情况，要是TM哥儿们发现某个数据库告诉他说，不好意思啊，我这儿失败了，那就尴尬了。或者是TM等了半天，某个数据库楞是死活不返回消息，跟失踪了一样，不知道在干嘛，也就麻烦了
这个时候TM直接判定这个分布式事务失败，毕竟某个数据库那里报了个错么，对不对，然后TM通知所有的数据库，全部回滚回滚回滚，赶紧的，做了啥操作都回滚，其实这里你可以认为是通知每个数据库，把自己本地的那个事务回滚不就得了，然后各个库都回滚好了以后就通知TM，TM就认为整个分布式事务都回滚了
但是呢，要是TM接收到所有的数据库返回的消息都是成功，那就happy了，直接发送个消息通知各个数据库说提交，兄弟们，然后各个数据库都在自己本地提交事务呗，就这么回事儿，提交好了通知下TM，TM要是发现所有数据库的事务都提交成功了，就认为整个分布式事务成功了