分布式事务设计文档

1 背景

---

　　在分布式环境下，每个应用使用不同的数据库。传统地，一个服务中使用一次事务，无法保证全局的事务特性。随着系统的发展，微服务拆分，分布式事务问题变得尤为严峻。
　　过去我们采用补数据的方式来应对这种紧急情况。但是在交易量增大、并发增多、业务复杂的情况下，仅靠人工处理难以满足系统发展的要求。
　　从长远来看，我们需要在系统间实现一套机制，当交易出现异常，能尽快地回滚到交易最初的数据，在出现紧急情况，我们能在系统间建立起一套良性的能满足定制化需求的方案。

2 实现目标

---

1. 建立起一套机制，通过框架来保证跨系统事务一致性问题。
2. 在这套机制下，提供个性化需求开发的入口。
3. 如支持手工重发处理、订单查询等。
4. 实现nutz和spring两套框架支持。
5. 只影响需要分布式事务问题的服务。 尽量减少开发工作量。

3 设计方向

---

3.1 事务的ACID特性

传统的关系性数据库支持事务，而事务体现在ACID四个特性上。
- Atomicity：原子性（要么都做，要么都不做）
- Consistency：一致性（数据库只有一个状态，不存在未确定状态）
- Isolation：隔离性（事务之间互不干扰）
- Durability： 永久性（事务一旦提交，数据库记录永久不变）

　　如果是单个应用，我们很容易通过关系型数据库来实现事务，而在微服务的环境下，每个应用都有单独的数据库，因此我们不能简单地依靠数据库来实现事务。
　　我们需要寻找在分布式环境，微服务架构中，寻找事务一致性的方案。

3.2 CAP原则和BASE理论

CAP原则和BASE理论被公认是分布式系统设计的基础和方向理论。

3.2.1 CAP原则

CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
- C：Consistency，一致性，所有数据变动都是同步的。
- A：Availability，可用性，即在可以接受的时间范围内正确地响应用户请求。
- P：Partition tolerance，分区容错性，即某节点或网络分区故障时，系统仍能够提供满足一致性和可用性的服务。

3.2.2 BASE理论

BASE 理论主要是解决 CAP 理论中分布式系统的可用性和一致性不可兼得的问题。BASE理论被认为是分布式系统理想的解决方案。
- BA：Basically Available，基本可用。
- S：Soft State，软状态，状态可以有一段时间不同步。
- E：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致。

3.3 思考的方向

BASE理论指示我们，如果无法同时实现CAP特性，可以牺牲强一致性，保证可用性。可以通过补偿来恢复最终一致性。

4 实现方案

4.1 全局事务

全局事务管理器一般使用XA二阶段提交(2PC)协议与数据库进行交互。

　XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。目前，Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。
　RM(Resource Manager)：资源管理器（这里可以是一个DBMS，或者消息服务器管理系统）应用程序通过资源管理器对资源进行控制，资源必须实现XA 定义的接口；
TM(Transaction Manager)：事务管理器，负责协调和管理事务，提供给AP应用程序编程接口以及管理资源管理器。
　实际上全局事务是把不同应用服务的事务绑定在一个事务，在数据库的层面实现了事务的问题。两阶段提交保证保证上下游系统都处理完自己的事情再提交事务。由此而引申出另外一个问题，可用性降低。全局事务会把数据锁定很长一段时间，上下游系统都要等待全局事务处理完才释放。
　全局事务是反伸缩的设计，反微服务的设计，会严重影响系统性能。虽然最终能解决事务问题，但不适合在微服务架构系统中使用。目前使用也比较少。

4.2 冲正

冲正指的是当原交易失败的时候，发起反交易，撤销原交易的处理结果。冲正在传统银行中使用较多。

上面是一个典型的跨系统冲正交易流程图：
1. 上游系统调用下游系统发起t1交易。
2. 下游系统处理完成，返回成功。
3. 上游系统继续处理内部业务失败，回滚本地事务。
4. 上游系统主动调用冲正交易-t1，冲掉原交易。
5. 下游系统返回冲正成功，此时两边数据一致。

但是这里存在很多问题：
1. 如果冲正交易调用失败/超时，怎么处理？
2. 需要开发人员把冲正交易编写到代码里面。
3. 将冲正业务渗透到了原交易，严重影响响应时间。
4. 无法监控、重发。
总结来说，发起反交易是分布式事务处理的一种思路，但是这种实现太简单，隐患太多。

4.3 tcc 模型

tcc 被认为是业务层的2PC方案，它不是在资源管理层实现的两阶段提交，而是在业务层实现。
Try: 尝试执行业务
完成所有业务检查(一致性)
预留必须业务资源(准隔离性)

Confirm:确认执行业务
真正执行业务
不作任何业务检查
只使用Try阶段预留的业务资源
Confirm操作满足幂等性

Cancel: 取消执行业务
释放Try阶段预留的业务资源
Cancel操作满足幂等性

与2PC协议比较
- 位于业务服务层而非资源层
- 没有单独的准备(Prepare)阶段，Try操作兼备资源操作与准备能力
- Try操作可以灵活选择业务资源的锁定粒度
- 较高开发成本

　这是一个典型的TCC模型图，业务活动管理器相当于2PC协议的TM，管理着服务事务的提交或者撤销。TCC模式是冲正模式的引申，它通过框架来实现，并且通过可以定时任务和消息等机制让交易实现最终一致性，并且通过框架尽量地实现稳定性、可扩展性。
　目前相关的开源插件有tcc-transaction 和 byte-tcc。蚂蚁金服有自己的tcc插件，不过要收费。

4.4 基于可靠消息的最终一致性

　　与第三方系统交互或者与下游系统(被动方)交互，如果被动方需要可靠的结果调用，并且调用满足幂等性（多次调用结果一致），同时对一定时间延迟不介意，可以使用基于可靠消息的最终一致性方案。
　　可靠消息，指的是当消息主动方，处理完本地事务时候，可靠地给被动方发送消息。

4.4.1 正常场景

1. 主动方应用先把消息发给消息中间件，消息状态标记为“待确认”；
2. 消息中间件收到消息后，把消息持久化到消息存储中，但并不向被动方应用投递消息；
3. 消息中间件返回消息持久化结果（成功/失败），主动方应用根据返回结果进行判断如何进行业务操作处理：
- 失败：放弃业务操作处理，结束（必要时向上层返回失败结果）；
- 成功：执行业务操作处理；
4. 业务操作完成后，把业务操作结果（成功/失败）发送给消息中间件；
5. 消息中间件收到业务操作结果后，根据业务结果进行处理；
- 失败：删除消息存储中的消息，结束；
- 成功：更新消息存储中的消息状态为“待发送（可发送）”，紧接着执行消息投递；
6. 前面的正向流程都成功后，向被动方应用投递消息；

4.4.2 异常场景

通过实现一定的机制，稳定可靠的保障在主动方处理完后准确地把消息传给消息消费被动方。

4.4.3 优点与适应场景

优点：
1. 降低主动方和被动方的耦合
2. 消息独立存储，利于扩展与伸缩

适应场景：
1. 内部跨系统的广播、短信通知
2. 第三方系统通知

4.5 几种方案对比

5 几个公司的方案选择

5.1 传统银行

传统银行使用冲正+对账的方式处理分布式事务问题。
1. 当交易失败的时候，发送反交易
2. 晚上对账，检查不平的账目，人工处理

5.2 支付宝

　　支付宝的分布式事务处理问题是行业里面的典范，一方面他的业务性质和交易量，决定了他的方案将面临巨大的考验。支付宝的成功也证明了他的技术架构的可行性。
　　现任CTO张立是支付宝第一代架构的创始人，2008年程立编写的ppt《大规模SOA系统中的分布式事务处理》，代表了支付宝对分布式事务处理方案的探索。

总结来说，程立基于BASE思想，提出了一套可选择策略的分布式处理方案。
1. 程立提出TCC模型、补偿操作、可靠消息一致性（两套实现方案）。
2. 基于策略模式，根据业务需要选择合适的分布式事务处理方式

5.3 蚂蚁金服第三方插件（收费）

蚂蚁金服提供了三套分布式事务处理方案：
1. 基于TCC 协议的处理方案，颗粒度控制到分支事务。
2. 框架托管模式（Framework-managed transactions，简称 FMT）
　　FMT是一种无侵入的分布式事务解决方案，该模式解决了分布式事务的易用性问题，在该模式下，开发者只需关注一阶段操作，框架会自动解析SQL语义，生成二阶段提交和回滚操作，使分布式事务的接入更便捷，该模式下对业务代码几乎无侵入，框架能够“自动化”地解决分布式架构下的数据一致性问题。
3. 基于是XA(eXtended Architecture)模式的分布式事务处理方案。
　　全面支持标准XA协议，覆盖面广，可无缝接入支持XA的数据库、消息等，帮助传统业务上云，并与自研数据库OceanBase共同打造实时数据一致性的整体解决方案。
蚂蚁金服的框架得到业务的考验，2017年的支付峰值25.6万笔/秒，相当于200万个分支事务，也就是这200万分支事务都要达到最终一致状态。

6 寻找适合公司架构的方案

6.1 改造思路

　　基于目前现有架构和基础，不适合对数据库侵入太大的方案。否则可能带来一定的风险和隐患。目前nutz和spring两套框架，尽量都要做兼容。对原来框架不影响，只对需要引入分布式事务的交易做控制。
　　基于上面的要求，我认为比较好的方式的引入一个合适的开源框架，在此基础上实现定制化开发需求。目前比较出名的开源框架tcc-transaction 和 byte-tcc，其中tcc-transaction相对较活跃，方案处理较详尽，可以考虑引进，适应本地框架后，尽量保留扩展性，在此基础上再考虑加入订单机制等个性化需求的开发。

7 参考资料