转载

微服务架构下分布式事务解决方案-hoop（一）

前言

数据库事务（简称：事务，Transaction ）是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。

事务拥有以下四个特性，习惯上被称为 ACID 特性：

原子性（Atomicity）：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
一致性（Consistency）：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束。除此之外，一致性还有另外一层语义，就是事务的中间状态不能被观察到（这层语义也有说应该属于原子性）。
隔离性（Isolation）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行，如同只有这一个操作在被数据库所执行一样。
持久性（Durability）：已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时，此操作将不可逆转。

什么是分布式事务？

微服务架构下分布式事务解决方案-hoop（一）

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

先来了解一下广为人知的 CAP 和 BASE 理论

微服务架构下分布式事务解决方案-hoop（一）

分布式事务

常见解决方案

二阶段协议，三阶段协议，MQ 事务消息，补偿，Saga，TCC等。本篇我们重点分享下TCC 的实现。

什么是 TCC ?

Try：完成所有业务检查，预留必须的业务资源，保证幂等性。
Confirm：真正执行的业务逻辑，不作任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性。
Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。

TCC 分布式事务模型包括三部分：

主业务服务（全局事务）：主业务服务为整个业务活动的发起方，服务的编排者，负责发起并完成整个业务活动。
从业务服务（分支事务）：从业务服务是整个业务活动的参与方，负责提供 TCC 业务操作，实现初步操作（Try）、确认操作（Confirm）、取消操作（Cancel）三个接口，供主业务服务调用。
业务活动管理器（事务管理器）：业务活动管理器管理控制整个业务活动，包括记录维护 TCC 全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时调用所有从业务服务的 Confirm 操作，在业务活动取消时调用所有从业务服务的 Cancel 操作。

微服务架构下分布式事务解决方案-hoop（一）

在设计一个分布式事务组件中，应该考虑哪些问题？

任何机器断电，crash怎么办？
网络节点问题如何处理？
什么时候提交|回滚全局事务？

走进 Hoop

了解 Hoop 之前，我简单先给大家介绍一些名词解释，默认约束

名词解释：

GlobalTransaction：全局事务（跟随主业务服务）
BranchTransaction：分支事务（跟随从业务服务）
GlobalTransactionStateConfirm：全局事务状态确认器【恢复事务需要】

约定俗成

全局事务执行过程中没有任何异常，commit 全局事务
全局事务方法中抛出异常(非指定异常)，直接回滚掉抛出异常前所有执行的分支事务，全局事务回滚。
hoop 推荐将网络超时的异常配置到 [delayHandleStep2Exceptions] 碰到这类异常，hoop 需要事务状态翻查器来决定事务提交|回滚。
hoop 推荐一定要为每一个全局事务配置一个 [GlobalTransactionStateConfirm] 以免异常情况下，错误的回滚掉了本该提交的事务。

Hoop 核心角色

TransactionInterceptor（全局事务拦截器）：管理全局事务，推进事务生命周期
CoordinatorInterceptor（分支事务协调者拦截器）：协调分支事务和全局事务
HoopRecoverBootStrap（恢复启动器）：管理，恢复异常事务
AbstractHoopStorageBootStrap（事务记录存储引擎）：存储全局事务和分支事务记录。

为什么 Hoop 高性能高吞吐量？

有很多 tcc 的文章中会常常提到 TransactionSynchronizationAdapter，用数据库的事务来推动二阶段执行。Hoop 完全摒弃了这一点，原因在于如果使用数据库的事务来推动分布式事务的二阶段，在T阶段分支事务较多的场景下，长事务会给 db 带来很大的资源消耗，会成为性能瓶颈。Hoop 所有执行节点都不会锁定 db 资源，没有长事务。而且 hoop目前提供了mysql 的存储引擎，支持使用者重写事务记录的存储引擎，redis，mongodb的引擎正在实现中。
Hoop 的恢复支持应用的所有机器并行，单台机器并发恢复，而且很好的控制了机器的资源。
Hoop 支持二阶段的异步提交。

下面是 Hoop 写一串伪代码，卢云（招行卡）给小强（建行卡）转账100元

微服务架构下分布式事务解决方案-hoop（一）

example1：A.doTry 成功，B.doTry 成功，hoop 自动提交 A.confirm B.confirm
example2：A.doTry 成功，B.doTry 失败，hoop 自动回滚 A.cancel B.cancel
example3：A.doTry 失败，hoop 自动执行 A.cancel

Hoop 异常情况分析

微服务架构下分布式事务解决方案-hoop（一）

Hoop 的异常事务恢复

微服务架构下分布式事务解决方案-hoop（一）

单个应用，所有部署的实例都可以并行恢复异常全局事务，提高系统吞吐量，节约机器资源。
事务恢复器主要是通过事务翻查器来推进全局事务的状态。

总结

TCC 分布式事务模型的业务实现特性决定了其可以跨 DB、跨服务实现资源管理，将对不同的 DB 访问、不同的业务操作通过 TCC 模型协调为一个原子操作，解决了分布式应用架构场景下的事务问题。TCC 模型也可以根据业务需要，做一些定制化的功能，比如交易异步化实现削峰填谷等。但是，业务接入 TCC 模型需要拆分业务逻辑成两个阶段，并实现 Try、Confirm、Cancel 三个接口，定制化程度高，开发成本高。

使用场景：由于从业务服务是同步调用，其结果会影响到主业务服务的决策，因此通用型 TCC 分布式事务解决方案适用于执行时间确定且较短的业务，比如互联网金融企业最核心的三个服务：交易、支付、账务。

后续给大家分享 hoop 的整体架构以及使用。

作者简介

雨人，铜板街交易团队研发工程师，2016 年 5 月加入团队，目前主要负责资金端项目的开发。

微服务架构下分布式事务解决方案-hoop（一）