• 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战

柔性事务在阿里内部的几种实现

使用场景：淘宝下单

通过消息队列传输事务，事务消息的特点是在事务 confirm 后再 publish，提交但没有 confirm 时会由队列服务主动查询。

存在问题：

1. 只能进行正向的事务补偿，在某些业务场景下会给带给客户不同的体验
2. 事务执行检查和回滚都需要靠开发人员来实现，这对于开发人员提供了额外更高的要求

示例如下，其中有个关键是要分解事务，交易的第一步是 扣减库存，库存没了就下不了单：

使用场景：支付宝业务和账务交互

XTS是TCC（Try/Confirm/Cancel）型事务，属于典型的补偿型事务。

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

XTS给开发人员提供了一个实现分布式事务的事务框架，主要负责事务日志的记录，事务的参与者需要实现XTS提供的接口，以实现XTS框架对事务参与者的事务协调和控制。与消息分布式事务相比，实现了更好的框架，但开发模式不变，也需要人工写补偿机制。

TCC 事务模型：

XTS 架构：

Try 准备阶段：

Confirm 确认阶段：

Cancel 回滚阶段：

定位：

• TXC完全能满足之前分布式事务平台所提供的对于事务服务高可用和事务最终一致性的基本业务要求。
• 标准模式（那就是说也有特殊模式）下无需开发人员自行进行事务回滚或补偿的代码，平台支持自动按事务中事务操作的顺序依次回滚和补偿（特殊模式也能手动写补偿）。
• 易用性是TXC的主要目标，在保证事务完整性的前提下，标准模式可不修改应用的代码，同时也提供之前平台中所提供的事务重试以及自定义事务模式。

开源版本 Seata：https://github.com/seata/seata (Simple Extensible Autonomous Transaction Architecture)

阿里云版本 GTS：https://help.aliyun.com/product/48444.html

目前只支持 Java

架构图中的RM（Resource Manager）为资源管理器，一般管理多个TXC数据源，负责在TXC客户端进行数据源访问时，与TXC服务器进行事务的注册和状态更新。TXC数据源是在原有的数据源基础上做了一层较薄的封装，因为TXC需要拦截和捕捉到所有TXC客户端对于数据库进行的数据修改，从而为事务的自动回滚提供数据的原始值。

相比于传统的两阶段提交方式，最大的区别在于XA在准备阶段是没有提交本地事务的，而TXC则是立即执行并可见，在隔离性级别上实现的是读未提交（read uncommitted），所以避免了在分布式事务中对于数据的长时间锁占用。也就是说，TXC在允许数据脏读的业务场景中，能充分发挥性能上的优势。比如商品在大促秒杀场景下，允许商品的库存在事务没有提交前给前端应用提供查询，只不过在最后订单扣减库存时进行控制，避免商品超卖现场的发生。如果业务场景不允许数据的脏读，TXC平台也支持select for update以及提供@hint的功能临时提升事务的隔离级别。

同时，TXC服务器端会记录当前处理事务对数据库中进行了修改数据的信息（行信息），当有其他事务也要对这些数据进行修改操作时，TXC服务端会协调两个事务间的执行，避免在第一个事务没有提交前，同样的数据会被另一个事务对该数据进行修改。从本质来说，将原来传统事务场景下，由数据库提供的锁机制提升到了TXC服务端进行了实现，这样相比于数据库锁的实现成本更加轻量，加上TXC本身服务能力的扩展能力，最终在同样实现事务隔离性的前提下，大大提升了整体的数据库处理吞吐率。

TXC两阶段提交实现。TXC也是基于两阶段提交理论实现，由TXC服务器负责整体的事务协调和管理，由部署在TXC客户端上的资源管理器组件实现各客户端与TXC服务器的事务注册、状态更新、提交等操作，一个标准的两阶段提交事务处理时序图如下图所示（Clt 是 Client 本地，HSF 是远程调用）。

回滚的原理：