分布式 事务(Atomioks)
简介：分布式事务指事务的参与者、支持事务的服务器、资源服务器、事务管理器分别位于不同的分布式系统的不同节点之上。本地事务是解决单个数据源上的数据操作的一致性，分布式事务是为了解决跨越多个数据源上数据操作的一致性问题。
一、分布式理论
1. ACID特性：原子性(A)、 一致性(C)、 隔离性(I)、持久性(D)；
2. CAP理论
A. 一致性(C)：C全称Consistency，指数据更新操作成功后，所有节点在同一时间的数据完全一致；
B. 可用性(A)：A全称Availability，指用户访问数据时，系统是否能在正常响应时间返回结果；
C. 分区容错性(P)：P全称Partition Tolerance，指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务；
D. CAP理论是在一个分布式系统中，最多只能满足C、A、P中两个条件，即组合有CA(如：MySQL/Oracle)、CP(如：Redis/MongoDB)、AP，根据业务来从中寻求平衡。
3. BASE理论
A. 基本可用(BA)：BA全称Basically Available，指分布式系统在出现故障时，系统允许损失部分可用性，即保证核心功能或者当前最重要功能可用；
B. 软状态(S)：S全称Soft state，指允许不同节点的副本之间存在暂时的不一致情况；
C. 最终一致性(E)：E全称Eventually consistent，指系统中数据副本最终能够一致，而不需要实时保证数据副本一致；
D. BASE理论是基于CAP理论中CA权衡而来的，核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
二、分布式事务协议
1. 2PC
A. 2PC全称Two-phase commit protocol，是两阶段提交协议，它引入了一个事务协调者角色，来管理各个参与者(各数据库资源)；
B. 两阶段分别是prepare和commit/rollback，在prepare阶段需要等待所有参与子事务的反馈(是否准备成功)，如果有一个参与者响应准备失败，那么第二阶段就向所有参与者发送回滚命令，反之发送提交命令；
C. 特点
优点：利用数据库自身的功能进行本地事务的提交与回滚；
缺点
同步阻塞：当协调者发送准备命令之后，那么本地资源都处于锁定状态，某一个参与者节点出现通信超时，其余参与者都会被动阻塞占用资源不能释放；
单点故障：一旦协调者发送准备命令之后发生故障，而参与者还都处于锁定资源的状态，无法完成事务commit操作，虽然协调者出现故障后，会重新选举一个协调者，可无法解决因前一个协调者宕机导致的参与者处于阻塞状态的问题；
数据不一致：协调者向参与者发送commit命令之后，一旦此时发生网络抖动，导致部分参与者接收到了commit请求并执行，可其他未接到commit请求的参与者无法执行事务提交，进而导致整个分布式系统出现了数据不一致；
2. 3PC
A. 3PC是三阶段提交协议，三阶段分别为CanCommit、PreCommit和DoCommit这三个阶段；
B. 3PC较2PC多了一个预准备阶段，就是在执行事务之前来确认参与者是否正常，防止个别参与者不正常的情况下，其他参与者都执行了事务，锁定资源；
C. 特点
优点：协调者和参与者都引入了超时机制，如果协调者挂了，时间到了参与者自动提交事务，解决了2PC的单点故障问题；
缺点：3PC还是没能从根本上解决数据一致性的问题，而且性能比2PC差。
三、分布式事务方案
1. 2PC二段提交
A. XA是两阶段提交事务的规范，JTA是Java实现XA的接口API，Atomikos是JTA具体的实现；
B. 二阶段提交协议是单JVM，多数据源提交事务。
2. TCC补偿事务
A. TCC是一种业务层面或者是应用层的两阶段提交，在业务员层体现就是三个方法，TCC采用补偿机制，针对每个操作，都要注册一个与其对应的确认和补偿(撤销)机制；
B. Try阶段主要是对业务系统做检测及资源预留，Confirm阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认Confirm阶段是不会出错的，即只要Try成功，Confirm就一定成功，Cancel阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放；
C. 优点：它的性能比2PC要高，因为不会有资源的阻塞，并且适用范围也大于2PC；
D. 注意点
幂等问题：因为网络调用无法保证请求一定能到达，所以都会有重调机制，因此对于 Try、Confirm、Cancel 三个方法都需要幂等实现，避免重复执行产生错误；
空回滚问题：指的是Try方法由于网络问题没收到超时了，此时事务管理器就会发出Cancel命令，那么需要支持Cancel在未执行Try的情况下能正常的Cancel；
悬挂问题：这个问题也是指Try方法由于网络阻塞超时触发了事务管理器发出了Cancel命令，但是执行了Cancel命令之后Try请求到了，所以空回滚之后还得记录一下，防止Try的再调用；
3. 本地消息表
A. 将业务的执行和将消息放入消息表中的操作放在同一个事务中提交；
B. 后台另起线程定时扫描本地消息表，根据消息状态执行对应操作。
4. 事务消息
A. 事务消息：指MQ提供的类似XA的分布式事务能力，通过事务消息可以达到分布式事务的最终一致性；
B. 半事务消息：指MQ收到了生产者的消息，但是没有收到二次确认，不能投递的消息。
可参考：消息队列之事务消息，RocketMQ 和 Kafka是如何做的
四、分布式事务框架
1. Seata：是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务，Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
可参考：常用的分布式事务解决方案
