4 -【 分布式事务 】- 1 分布式事务基础

1 分布式事务产生的背景

在微服务环境下，因为会 根据不同的业务会拆分成不同的服务，比如 会员服务、订单服务、商品服务等，让专业的人做专业的事情，每个服务都有自己独立的数据库，并且是独立运行，互不影响。

服务与服务之间通讯采用 RPC 远程调用技术，但是每个服务中都有自己独立的数据源，即自己 独立的本地事务。两个服务相互通讯的时候，两个本地事务互不影响，从而出现分布式事务产生的原因。

传统项目大部分情况下，不会产生分布式事务，但是在项目中如果采用多数据源方式，也会产生分布式事务。

分布式事务案例说明 - 下单扣库

在电商系统中，下单和扣库存如何保持一致？

比如：用户先下单后，扣库存失败，那么将会导致超卖；如果下单不成功，扣库存成功，那么会导致少卖。这两种情况都会导致运营成本增加，在严重情况下需要赔付。

主要涉及两个微服务：订单服务 和 库存服务。

如果订单服务抛异常：

因为订单与库存服务不在同一个微服务中，相互的数据源都是独立的，每个独立的数据源中都有自己独立的事务，该事务称为 本地事务。

本地事务源的有效范围是在当前同等的 JDBC 连接中。

扫描二维码关注公众号，回复： 10122537 查看本文章

2 解决分布式事务基本思路

在学习解决分布式事务基本思路之前，大家要熟悉一些基本解决分布式事务概念名词。

比如：CAP 与 Base 理论、柔性事务 与 刚性事务、理解最终一致性思想，JTA + XA、两阶段与三阶段提交等。

这些名词在后期学习一些第三方分布式事务解决框架中用到，比如国产的 LCN、阿里的 GTS 框架等。

2.1 ACID 酸碱平衡理论

如何保证强一致性呢？在学习关系型数据库的时候都学习了 ACID 原理，这里对 ACID 做个简单的介绍。如果想全面的学习 ACID 原理，请参考 ACID。

关系型数据库天生就是解决具有复杂事务场景的问题，关系型数据库完全满足 ACID 的特性。

数据库管理系统中事务（transaction）的四个特性（分析时根据首字母缩写依次解释）：

• 原子性（Atomicity）
• 一致性（Consistency）
• 隔离性（Isolation）
• 持久性（Durability）

所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。（执行单个逻辑功能的一组指令或操作称为事务）。

2.2 CAP（帽子原理）

由于对系统或者数据进行了拆分，我们的系统不再是单机系统，而是分布式系统，针对分布式系统的 CAP 原理包含如下三个元素。

• C：Consistency，一致性。在分布式系统中的所有数据备份，在同一时刻具有同样的值，所有节点在同一时刻读取的数据都是最新的数据副本。

• A：Availability，可用性，好的响应性能。完全的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并进行响应。

• P：Partition tolerance，分区容忍性。尽管网络上有部分消息丢失，但系统仍然可继续工作。

CAP 原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数 web 应用，其实并不需要强一致性，因此 牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是 不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

2.3 Base（碱）

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写，由 eBay 架构师 Dan Pritchett 于 2008 年在《BASE: An Acid Alternative》（论文地址点 这里）论文中首次提出。BASE 思想与 ACID 原理截然不同，它满足 CAP 原理，通过牺牲强一致性获得可用性， 一般应用于服务化系统的应用层或者大数据处理系统中，通过达到最终一致性来尽量满足业务的绝大多数需求。

BASE 模型包含如下三个元素：

• BA：（Basically Available ），基本可用。
• S：（Soft State），软状态，状态可以在一段时间内不同步。
• E：（Eventually Consistent ），最终一致，在一定的时间窗口内， 最终数据达成一致即可。

关于最终一致的几种变种参见上面，在实际系统实践中，可以将若干变种结合起来，来实现各种业务需求。

支付项目

支付项目一般有两种回调方式：

• 方式一：同步回调地址。支付完成后，支付宝采用浏览器重定向到回调方。
• 方式二：异步回调地址。支付完成后，支付宝采用类似 HttpClient 方式调用请求方的支付通知接口。

3 柔性事务和刚性事务

• 柔性事务满足 BASE 理论（基本可用，最终一致）
• 刚性事务满足 ACID 理论

本文主要围绕分布式事务当中的柔性事务的处理方式进行讨论。

柔性事务分为：

1. 两阶段型
2. 补偿型
3. 异步确保型
4. 最大努力通知型 几种。 由于支付宝整个架构是 SOA 架构，因此传统单机环境下数据库的 ACID 事务满足了分布式环境下的业务需要，以上几种事务类似就是针对分布式环境下业务需要设定的。

4 分布式事务常见解决方案

4.1 传统模式 Jta+Atomikos

传统项目中，比如项目中使用到多数据源的时候大多数采用 jta+Atomikos 解决分布式事务问题，jta+Atomikos 底层是基于 XA 协议的两阶段提交方案。

XA协议

XA 事务的基础是 两阶段提交协议。需要有一个事务协调者来保证所有的事务参与者都完成了准备工作(第一阶段)。如果协调者收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。Mysql 在这个 XA 事务中扮演的是参与者的角色，而不是协调者(事务管理器)。

JTA

JTA（java Transaction API）是 JavaEE 13 个开发规范之一。java 事务 API，允许应用程序执行分布式事务处理——在两个或多个网络计算机资源上访问并且更新数据。JDBC 驱动程序的 JTA 支持极大地增强了数据访问能力。事务最简单最直接的目的就是保证数据的有效性，数据的一致性。

Atomikos

Atomikos TransactionsEssentials 是一个为 Java 平台提供增值服务的并且开源类事务管理器。

分布式事务解决方案采用 Atomikos 后台管理系统。

4.2 两段提交协议

第一阶段：
准备阶段：协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，则会写 redo 或者 undo 日志，让后锁定资源，执行操作，但并不提交。

第二阶段：
执行阶段：如果每个参与者明确返回准备成功，则协调者向参与者发送提交指令，参与者释放锁定的资源，如何任何一个参与者明确返回准备失败，则协调者会发送 中止指令，参与者取消已经变更的事务，释放锁定的资源。

两阶段提交方案应用非常广泛，几乎所有商业OLTP数据库都支持XA协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

缺点：如果协调者宕机，参与者没有协调者指挥，则会一直阻塞。

4.3 三段提交协议

三阶段提交协议是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题，并且把两个阶段增加为三个阶段：

询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是还是不是，而不需要做真正的操作，这个阶段超时导致中止。

准备阶段：如果在询问阶段所有的参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作，但是不提交操作；如果在询问阶段任何参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻辑与两阶段提交协议的的准备阶段是相似的，这个阶段超时导致成功

提交阶段：如果每个参与者在准备阶段返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源，这里的逻辑与两阶段提交协议的提交阶段一致

4.4 两段提交和三段提交协议区别

增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生在准备阶段以后，协调者和参与者执行的任务中都增加了超时，一旦超时，协调者和参与者都继续提交事务，默认为成功，这也是根据概率统计上超时后默认成功的正确性最大

三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生超时，系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源。