前言

本文主要讲解不同场景下分布式事务的解决方案，以及区别和相关理论。（部分图片来自网络）

一、分布式事务的相关理论

CAP理论：

一致性（Consistency）
可用性（Availability）
分区容错（Partition-tolerance）
一个分布式系统最多只能满足以上的两项，分区容错性是分布式系统必然需要面对和解决的问题，因此在一些大型互联网公司都会把精力放在如何在C（一致性）和A（可用性）之间寻求平衡。

BASE理论

基本可用（Basically Available）
指分布式系统在出现不可预知故障的时候，允许损失部分可用性。
软状态（ Soft State）
指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致（ Eventual Consistency）
强调的是所有的数据更新操作，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
BASE理论即在整体可用的情况下，满足最终一致性，BASE理论可以说是CAP理论的拓展。

二、分布式事务解决方案

1.跨库事务（强一致性事务）

跨库事务即在一个jvm内调用两个数据库。
XA是由X/Open组织提出的分布式事务的规范，主要定义了：

（全局）事务管理器（Transaction Manager），承担协调者（中间人transactionmanager）的身份
（局部）资源管理器（Resource Manager），通常是数据源
XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。

JTA是XA协议在JAVA上上的实现，主要定义了：

事务管理器的接口javax.transaction.TransactionManager，定义了有关事务的开始、提交、撤回等操作。
满足XA规范的资源定义接口javax.transaction.xa.XAResource，一种资源如果要支持JTA事务，就需要让它的资源实现该XAResource接口，并实现该接口定义的两阶段提交相关的接口。

XA/JTA简单来说就是一个两阶段提交协议，以下图举例。

准备阶段：协调者（事务管理器Transaction Manager）询问每个数据源（资源管理器 Resource Manager）。事务管理器询问订单库和库存库，数据是否准备好，是否可以提交。
执行阶段：如果数据源都回复可以提交数据，则协调者会把每个数据源的数据提交。如果数据源因为资源不足（库存不足）或网络连接失败等情况，回复不可以提交，则协调者会把每个数据源的数据进行回滚。

常见的JTA实现Atomikos，TransactionEssentials。

2.跨JVM事务（柔性事务）

XA/JTA是强一致性事务，在分布式系统中体现为CP。虽然数据强一致，但在大型互联网公司通常对AP与CP都有需求，此种方案明显无法被使用。大多数互联网公司都采用基于BASE理论的柔性事务，兼顾AP与CP。

2.1.可靠消息最终一致性方案

可靠消息最终一致性方案是基于消息中间件的解决方案。
在确保消息服务可用的前提下，由生产者预发送消息给独立消息服务存储到数据库，之后执行业务逻辑，执行完之后向消息服务发送确定发送消息，独立消息服务将此消息发送到消息队列中。此时消息消费者，在保证幂等性的前提下，消费消息，消费成功后并手动ack。如果在确认发送消息或ack因网络等原因，一直无法执行时。独立消息服务可以通过定时器，定时去相应服务查询相关数据的状态，进行自动确认发送和自动ack。
基于普通的消息队列中间件
例子如下：
在这里插入图片描述
独立消息服务定时任务的作用就是解决异常情况下，消息无法发送和消费成功无ACK的情况。但是如果消息消费的过程中出现了异常情况，且多次重试都无法成功的情况下，就需要人工干预。

2.2.TCC(Try-Confirm-Cancel)两阶段补偿型方案

累了，TCC(Try-Confirm-Cancel)就不再赘述了。T指资源预留，C资源确认,C资源回滚。
如下单，通常情况下只用写一个接口。使用TCC方案下，需要写三个接口，一个是资源预留接口，资源预留通常新增数据库字段控制。一个是资源预留成功情况下的资源确定接口，一个是资源预留失败情况下的资源回滚接口。
TCC开源框架实现：
Atomikos，tcc-transaction，ByteTcc