不管是流程本身导致分布式的数据库调用，比如：订单微服务下单，调用库存微服务扣减库存（此时数据库可能是一个数据库），还是数据库本身的分布式，比如：单个流程调用涉及订单数据库和库存数据库两个数据库（此时调用流程可能是在一个应用中），都会导致分布式事务的问题
CAP理论中的P主要指的是分区可容忍性，也即在网络分区的情况下，系统能否工作（不管工作得是否正常但是起码得能工作），但是由于不管你允不允许，在分布式系统下网络分区都会有可能发生，除非你是单体应用，所以P是一定要被选择的，所以总的选择只有AP和CP两种，前一种保证了一致性和分区可容忍性也就是说，当网络分区发生的时候，为了保证数据的一致性，服务整体不可用，也即强一致性，后一种保证了可用性和分区可容忍性，也即当网络分区发生的时候，为了保证服务的可用性，数据会不一致，一般都会设置成最终一致性。
BASE理论是对CAP理论中AP的一个扩展，它通过牺牲强一致性来获得可用性，它的核心在于：基本可用（Basic Available），软状态（Soft State）以及最终一致性（Eventually Consistent）。基本可用是指分布式系统出现故障时，允许其损失系统的部分可用性，比如响应时间，但是要保证系统基本可用；软状态是指允许系统中存在中间状态，比如订单中的“支付中”最后会变成”支付成功“；最终一致性是指系统中各个节点的数据副本经过一段时间的同步最终能够达到一致性的状态。
分布式事务部分遵循ACID规范：严格遵循原子性；对于事务完成后的一致性严格遵循，事务中的一致性可适当放宽；对于并行事务间的隔离性严格遵循，事务中间结果可见性允许安全放款；严格遵循持久性
1.强一致性分布式事务解决方案——两阶段提交/XA：
XA是由X/Open组织提出的分布式事务的规范，XA 事务由一个或多个资源管理器（RM）、一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成，本地的数据库如mysql扮演RM角色，应用本身同时扮演TM角色的情况下，具体执行过程如下：
应用首先获取业务流程涉及到的各个资源管理器的XA连接，然后设置全局事务ID并且基于此向每个资源管理器发送start命令从而开启分支事务，开启分支事务后通过XA连接使得不同的资源管理器执行不同的操作（此时资源管理器也即数据库会基于线性化的事务隔离模式执行对应的操作，同时记录Redo Log和Undo Log），在针对每个资源管理器的操作调用完成后向每个资源管理器发送end命令代表分支事务已经结束，最后启动两阶段提交：第一阶段（prepare）：向所有的资源管理器发送prepare命令并等待资源管理器报告已准备就绪；第二阶段 (commit/rollback)：确认所有参与者(RM)都ready后，向所有参与者发送commit命令，如果有不ready的情况则向所有参与者发送rollback命令。
总而言之就是：xa start -> execute * n -> xa end -> [xa prepare -> xa commit/rollback](两阶段提交)
2.最终一致性分布式事务解决方案：
在强一致性分布式事务解决方案下，由于需要长时间的锁住资源从而很容易造成系统性能低下，另外由于网络的不稳定性往往会导致完成强一致性分布式事务的提交操作难以完成。为了解决对应的问题，业界引入了最终一致性分布式事务解决方案：每个服务都存在中间状态，服务与服务之间不必保持强一致性，允许在某个时刻查询出来的数据存在短暂的不一致，从而提高了系统的整体性能并降低了分布式事务执行过程中出错的概率。
在最终一致性分布式事务解决方案中往往需要以下几种操作接口：1. 可查询操作接口：所有操作的状态需要可以查询 2. 幂等性操作接口：操作本身需要做到幂等从而满足可重试性 3. TCC操作接口：Try，Confirm以及Cancel接口，具体会在后文中给出 4. 可补偿操作接口：执行的操作需要有补偿接口从而使得处于不正常状态的数据补偿（回滚）回正常状态，
目前常用的最终一致性分布式事务解决方案有以下3种：
TCC解决方案：对于所有的分布式事务都经过三个阶段：1. Try阶段：进行业务的一致性检查以及资源的预留（比如库存数据库减去库存数量，增加待扣减库存）2. Confirm阶段：如果Try阶段没什么问题，就直接进行实际的业务操作（比如库存数据库抹去待扣减库存）3. Cancel阶段：如果Try阶段出现Exception，则Cancel回滚之前的资源预留操作
可靠消息最终一致性解决方案：事务的发起方执行完本地事务之后发出一条消息给其他事务的参与方，同时需要保证消息的消费者一定能够接收到这条消息并处理成功，另外需要引入消息确认服务来保证本地事务和消息发送的原子性和消息恢复服务来保证事务参与方接收消息的可靠性，也即保证本地事务完成以后肯定可以发送消息并让参与方接收到消息
最大努力通知型解决方案：该解决方案允许丢失消息（时间阶梯型通知规则），但是需要业务主动方提供事务状态查询接口，以便在消息彻底丢失后（主动方已经尽最大努力了）业务被动方主动调用并恢复丢失的业务
