1.什么是事务：一组操作，要么全部执行成功，要么全部回滚。事务的特性ACID。单机事务：只涉及到一个物理数据源
2.什么是分布式事务：分布式环境下的事务，涉及到多个应用或多个数据源。涉及两个及以上的网络主机的数据库事务
3.分布式事务场景：跨库事务、跨服务事务、混合事务
4.理论
实际中解决方案很多，例如，lcn,最大努力消息通知，本地事务表，阿里开源框架Seta等等，但是最终的解决思路基本上可以分为两种：基于XA协议的实现，基于补偿机制的实现。
在讨论具体的解决思路和方案之前，我们需要先了解一下分布式事务中最最基本的概念：
说这些概念，必须从XA协议说起，我们可以从XA的一个解决思路，来引入这些概念：
DTP模型（分布式事务处理模型）
（1）TM：事务管理者（管理全局的事务）
负责整体事务的提交与回滚的指令的触发，扮演事务的总体协调者角色。
（2）RM：资源管理者（事务参与者）（管理本地的事务）
负责本地事务的提交，同时完成分支事务的注册、锁的判定，扮演事务参与者角色。
（3）AP: 应用程序
基于XA协议思路（2PC）：
XA协议的主要是2pc（两阶段提交的思路）
（1）第一阶段是预备阶段，所有参与者都将本事务能否成功的信息反馈发给协调者；
a.事务管理者（TM）向所有事务参与者（RM）发送事务内容，询问是否可以提交事务，并等待参与者回复;
b.事务参与者收到事务内容，开始执行事务操作，将undo 和 redo 信息记入事务日志中（但此时并不提交事务）。
（2）第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚，见下图。
XA事务提交成功
XA事务提交失败
分布式事务：
如果一阶段执行成功，则二阶段必须成功。所以二阶段接口要支持幂等（confirm/cancel）
事务悬挂：先执行cancel,再执行try. 原因：try是RPC调用，超时，TM发出cancel的调用，cancel调成功，此时try调用才到达。
针对事务悬挂的解决方案是：增加“分支事务记录表”，在执行一阶段的操作时，判断是否有二阶段事务记录，如果有则不执行
事务提交：
将本次事务中的所做的所有的变更，持久化到数据库的过程，即保存到磁盘等持久性存储介质中。
事务回滚：不会将本次事务中的所做的所有的变更，持久化到数据库中
