分布式事务实现

在分布式系统中，同时满足“CAP定律”中的“一致性”、“可用性”和“分区容错性”三者是不可能的。在互联网领域的绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。

XA

XA规范主要定义了事务管理器(Transaction Manager)和资源管理器(Resource Manager)之间的接口. XA引入事务管理器是因为在分布式系统中，从理论上讲两台机器上无法达到一致的状态，需要引入一个外部点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源, 资源管理器负责控制和管理实际资源。XA是一个两阶段提交协议，该协议分为以下两个阶段：

事务协调器要求每个涉及到事务的数据库预提交，并反映是否可以提交。
事务协调器要求每个数据库提交数据。

如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。

JTA

JTA作为JAVA平台上的事务规范，同时定义了对XA事务的支持；在JTA中，事务管理器抽象为javax.transaction.TransactionManager接口，通过底层事务服务（即JTS）实现,JTA仅仅定义了接口，具体的实现则是由供应商(如J2EE厂商)负责提供，目前JTA的实现主要由J2EE容器所提供的JTA实现(如JBOSS)和独立的JTA实现(如JOTM，Atomikos)。

JTA本质上是两阶段提交，实现复杂，牺牲了可用性，对性能影响较大, 适合对数据强一致(其实也不能100%保证强一致)要求很高的关键领域; 大部分互联网业务都不会采用两阶段提交的方式。

链式事务管理

这种方式也Spring提供的，可以将两个或多个数据库资源的事务串联到一起，公用一个TransactionManager来实现对多个资源的事务。配置方式如下：

  <bean id="transactionManager" class="org.springframework.data.transaction.ChainedTransactionManager">
  <property name="transactionManagers">
    <list>
      <bean
        class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource1" />
      </bean>
      <bean
        class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource2" />
      </bean>
    </list>
  </property>
</bean>
 </code>

针对多个数据库实现事务。使用这种方式时，在Spring事务提交的时候，它会依次调用里面的多个dataSource的commit()方法，如果业务方法出错，就会按照相反的顺序调用rollback()方法。这种方法可能会出现先前的提交成功，之后的提交失败，所以还是会有事务失败的可能。

实现简单，但可能会出现先前的提交成功，之后的提交失败，所以还是会有事务失败的可能

最大努力一次提交(Best Efforts 1PC)

在一个系统中使用数据库和带事务功能的消息中间件，业务流程如下

开始消息事务
发送消息
开始数据库事务
更新数据库
提交数据库事务
提交消息事务

有两个事务，分别是DB的和JMS的事务，事务的开启和提交都是相互独立的。依次提交这两个事务，只要第二个事务顺利提交，整个方法就能够保证数据的一致性。实际上，在绝大多数情况下，只要数据库和MQ能够正常访问，这也确实能够保证。所以，这种方式就叫’最大努力’一次提交。

使用这种方式，事物提交的顺序是非常重要的。假设在提交messaging transaction的时候发生错误，这时数据库的事务已经提交，无法回滚，但是消息的事务被回滚，那么这一条消息会被重新放回队列中，该业务方法会被再次触发，再次在一个新的事务中处理。但是，这时数据的处理已经完成，只是最后JMS的事物提交出错，那么就需要通过防止重复提交的方式，来避免数据库的再次处理。

事务补偿型(TCC型事务–Try/Confirm/Cancel)

其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：

Try 阶段主要是对业务系统做检测及资源预留
Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的, 即：只要Try成功，Confirm一定成功
Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放

在一个长事务，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B所处理时间可能比较长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。这样的事务模型，是牺牲了一定的隔离性和一致性的，但是提高了事务的可用性。

与两阶段提交相比实现及流程相对简单，但应用层要写很多补偿代码(而且补偿也不能保证一定成功)

本地流水表实现最终一致性

以电商下单场景为例，主要涉及到两个操作，扣减库存和生成订单,因为两个操作在不同的数据库，无法保证强一致性,可以通过本地流水表来实现最终一致性，具体流程如下:

生成交易操作唯一标示token
事务一(库存系统):
- 冻结库存
- 根据下单流水号生成商品的库存冻结记录,冻结记录主要包括skuId,token,冻结数量,状态 .状态有3种状态: 已冻结，下单成功扣减，下单失败释放,初始状态为已冻结
如果事务一失败，直接返回；如果成功进入事务二
事务二(订单系统, 本地事务)：根据token生成订单,订单的状态主要包括：未支付,已支付,超时未支付,订单的初始状态为未支付
事务二如果成功，则进行后续的流程,
事务二如果失败，调用库存系统的回滚接口，返回下单失败;
定时任务: 因为存在事务一成功而事务二失败的情况，这样会冻结商品的部分库存，所以可以捞取出创建超过一定时间状态为已冻结的所有冻结记录，根据每个冻结记录的token去订单表查询，若不存在对应的订单，则将冻结记录的状态更新为下单失败释放，并回滚商品库存数量

异步确保型

将一些有同步的事务操作变为异步操作，避免对数据库事务的争用；继续以以电商下单场景为例，支付成功后增加用户积分；

事务一(订单系统)，订单状态修改为支付成功，发送支付成功消息
事务二(用户系统)，用户系统接到支付成功消息后，增加用户积分

MQ事务消息

一些第支持事务消息MQ，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，其思路大致为：

第一阶段Prepared消息，会拿到消息的地址。
第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。

在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，是回滚还是继续发送确认消息。这样就保证了消息发送保证与本地事务同时成功或同时失败

分布式事务实现的原则

大事务拆成小事务，每个小事务都是单机上的事务
补偿 + 重试，业务上设计补偿机制，而且保证补偿失败后有重试机制
幂等, 保证每次事务操作是幂等的，保证幂等的方式可以采用：
- 状态值，每次写操作的时候检查状态值
- 唯一标示，每次写操作都带入业务唯一标示