支付宝 分布式事务服务 DTS 一

分布式事务服务 DTS 一

更多干货

• 分布式事务处理一
• 分布式事务二
• 分布式事务处理三
• 分布式事务四_基于可靠消息的最终一致性
• 分布式事务五_基于可靠消息的最终一致性_异常流程
• 分布式事务六_常规MQ队列
• 分布式事务七_幂等性设计
• 分布式事务八_可靠消息最终一致性方案
• 分布式事务九_基于可靠消息的最终一致性代码
• 分布式事务10_最大努力通知形势
• 柔性事务解决方案：TCC（两阶段型、补偿型）
• 支付宝 分布式事务服务 DTS 一
• 分布式事务服务 DTS二
• 分布式事务服务 DTS三
• 支付宝 分布式事务服务 DTS四

分布式事务服务简介 产品详情

注意：为向用户提供更加优质的服务，蚂蚁金融云已对中间件产品完成进一步升级改造，并计划于 2018 年 3 月 31 日下线本产品。

分布式事务服务（Distributed Transaction Service，简称 DTS）是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 Jar 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。

核心特性

传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下，ACID 模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题，但是 2PC 是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模达到千万级以上时，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。基于此，我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案，这就是 DTS。DTS 在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。

简单的说，DTS 框架有如下特性：

• 最终一致：事务处理过程中，会有短暂不一致的情况，但通过恢复系统，可以让事务的数据达到最终一致的目标。
• 协议简单：DTS 定义了类似 2PC 的标准两阶段接口，业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。
• 与 RPC 服务协议无关：在 SOA 架构下，一个或多个 DB 操作往往被包装成一个一个的 Service，Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上，与底层协议无关。
• 与底层事务实现无关： DTS 是一个抽象的基于 Service 层的概念，与底层事务实现无关，也就是说在 DTS 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列存数据库 HBase，只要将对其的操作包装成 DTS 的参与者，就可以接入到 DTS 事务范围内。

核心概念

在 DTS 内部，我们将一个分布式事务的关联方，分为发起方和参与者两类：

• 发起方： 分布式事务的发起方负责启动分布式事务，触发创建相应的主事务记录。发起方是分布式事务的协调者，负责调用参与者的服务，并记录相应的事务日志，感知整个分布式事务状态来决定整个事务是 COMMIT 还是 ROLLBACK。
• 参与者：参与者是分布式事务中的一个原子单位，所有参与者都必须在一阶段接口（Prepare）中标注（Annotation）参与者的标识，它定义了 prepare、commit、rollback 3个基本接口，业务系统需要实现这3个接口，并保证其业务数据的幂等性，也必须保证 prepare 中的数据操作能够被提交（COMMIT）或者回滚（ROLLBACK）。从存储结构上，DTS 的事务状态数据可以分为主事务记录（Activity）和分支事务记录（Action）两类：
• 主事务记录 Activity：主事务记录是整个分布式事务的主体，其最核心的数据结构是事务号（TX_ID）和事务状态（STATE），它是在启动分布式事务的时候持久化写入数据库的，它的状态决定了这笔分布式事务的状态。
• 分支事务记录 Action：分支事务记录是主事务记录的一个子集，它记录了一个参与者的信息，其中包括参与者的 NAME 名称，DTS 通过这个 NAME 来唯一定位一个参与者。通过这个分支事务信息，我们就可以对参与者进行提交或者回滚操作。

基础术语

1. 分布式事务（Distributed Transaction）

• 事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上

2. 最终一致（Eventually consistent）

• 事务处理过程中，在特殊异常的情况（比如发起方crash）会有短暂不一致的情况（根据经验，一般概率小于0.01%），但通过恢复系统，可以让事务的数据达到最终一致的目标，用户无需感知

3. 两阶段提交（2PC）

• 一种协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法

4. 发起方（Coordinator）

• 是指一笔分布式事务的发起方，一般是一个入口的业务系统

5. 参与者（Participant）

• 一笔分布式事务的参与者，提供符合 2PC 规范的接口实现

6. 主事务记录 (Activity)

• 是指用来代表一笔分布式事务的数据存储记录

7. 分支事务记录 (Action)

• 是指代表一个参与者的数据存储记录

8. 事务号（Transaction Identification）

• 一笔分布式事务的唯一编号

9. 业务类型（Business Type）

• 是指发起方用来发起分布式事务的业务类型，比如交易支付

10. 业务号（Business Identification）

• 是指代表发起方发起分布式事务的主体，比如交易号

11. 事务恢复（Transaction recovery）

• 是指一笔分布式事务二阶段失败之后，由恢复系统发起的事务恢复行为

参考文档

• https://www.cloud.alipay.com
• https://www.cloud.alipay.com/docs/2/46886