网站架构师的工作内容( 分布式事务应用架构（一）：事务1.1什么是事务数据库 )

　　网站架构师的工作内容(

分布式事务应用架构（一）：事务1.1什么是事务数据库

)

　　分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构都涉及到的事情。尤其是在这几年越来越火的微服务架构中，几乎可以说是在所难免。本文将为您介绍分布式事务的方方面面。

　　事务

　　1.1 什么是交易

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

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

　　1.2 地方事务

　　起初，事务仅限于对单个数据库资源的访问控制：

　　在架构面向服务之后，事务的概念被扩展到了服务。如果将单个服务操作视为一个事务，那么整个服务操作只能涉及单个数据库资源：

　　这种基于单一服务和单一数据库资源访问的事务称为本地事务（Local Transaction）。

　　分布式事务

　　本地事务主要限于单个会话，不涉及多个数据库资源。但是，在基于 SOA（Service-Oriented Architecture）的分布式应用环境中，越来越多的应用需要访问多个数据库资源，多个服务被收录在同一个事务中。分布式事务应运而生。

　　最早的分布式事务应用架构很简单，不涉及服务之间的访问调用，只有服务内部的操作涉及到多个数据库资源的访问。

　　当一个服务操作访问不同的数据库资源，希望他们的访问具有事务特性时，就需要使用分布式事务来协调所有的事务参与者。

　　对于上面介绍的分布式事务应用架构，虽然一个服务操作会访问多个数据库资源，但毕竟整个事务仍然控制在一个服务内。如果一个服务操作需要调用另一个服务，那么事务就需要跨越多个服务。在这种情况下，当一个从一个服务开始的事务调用另一个服务时，需要通过某种机制转移到另一个服务中，这样被调用的服务访问的资源会自动加入到事务中。. 下图反映了这样一个跨多个服务的分布式事务：

　　如果将以上两种场景（一个服务可以调用多个数据库资源或调用其他服务）结合起来进行扩展，整个分布式事务的参与者将形成如下图所示的树状拓扑结构。在跨服务分布式事务中，事务的发起者和提交者都是相同的。它可以是整个调用客户端，也可以是客户端调用的第一个服务。

　　与基于单一数据库资源访问的本地事务相比，分布式事务的应用架构更加复杂。

　　在不同的分布式应用架构下，实现分布式事务需要考虑的问题并不完全相同，比如多资源的协调、事务的跨服务传播等。实现机制也是复杂多变的。虽然有这么多工程细节需要考虑，但分布式事务的核心是它的 ACID 特性。因此，要想了解一个分​​布式事务，首先要了解它是如何实现事务ACID特性的。

　　下面将从两种最常见的分布式事务模型入手，重点分析分布式事务的基本共同点，即如何保证分布式事务的ACID特性。

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

　　1. 基于XA协议的两阶段提交

　　XA 是一种分布式事务协议，由 Tuxedo 提出。XA 大致分为两部分：事务管理器和本地资源管理器。本地资源管理器通常由数据库实现。例如Oracle、DB2等商业数据库实现了XA接口，事务管理器作为全局调度器，负责各种本地资源的提交和回滚。XA实现分布式事务的原理如下：

　　一般来说，XA协议比较简单，商业数据库一旦实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有一个致命的缺点，就是性能不理想，尤其是在交易订单环节，往往并发量非常高，XA无法满足高并发场景。XA 目前在商业数据库中得到支持，而不是在 mysql 数据库中得到理想的支持。mysql的XA实现没有记录prepare阶段日志，主备库切换导致主备库数据不一致。很多nosql不支持XA，这使得XA的应用场景非常狭窄。

　　2.消息事务+最终一致性

　　所谓消息事务就是基于消息中间件的两阶段提交。它本质上是消息中间件的特殊用途。它将本地事务和消息发送放在分布式事务中，以确保本地操作成功。并且外部消息成功，或者都失败，开源的RocketMQ支持这个特性，具体原理如下：

　　1、系统向消息中间件发送初步消息

　　2、消息中间件保存准备好的消息并返回成功

　　3、A 执行本地事务

　　4、A向消息中间件发送提交消息

　　通过以上4个步骤完成一个消息事务。对于以上4步，每一步都可能出现错误，下面一一分析：

　　基于消息中间件的两阶段提交常用于高并发场景。一个分布式事务拆分为消息事务（系统A本地操作+消息发送）+系统B本地操作，其中系统B的操作由消息Drive决定，只要消息事务成功，那么操作必须成功，并且必须发送消息。这时B会收到消息进行本地操作。如果本地操作失败，消息会被重新发布，直到B操作成功，这就是变相实现A和B的分布式事务。原理如下：

　　上述方案虽然可以完成A和B的操作，但A和B并不是严格一致的，而是最终一致的。我们在这里牺牲了一致性以换取显着的性能改进。当然，这种玩法也是有风险的。如果 B 执行不成功，则一致性将被破坏。玩不玩，要看企业能承受多大的风险。

　　3.TCC模型

　　与 XA 等传统模型相比，TCC（Try-Confirm-Cancel）分布式事务模型的特点是不依赖资源管理器（RM）对分布式事务的支持，而是通过对分布式事务的分解来实现分布式事务。业务逻辑事务。

　　TCC模型认为，对于业务系统中的特定业务逻辑，对外提供服务时，必须接受一些不确定性。即对业务逻辑的初始操作的调用只是临时操作，调用它的主业务服务保留后续取消的权利。如果主业务服务认为全局事务应该回滚，它会请求取消之前的临时操作，这对应于从业务服务的取消操作。当主业务认为应该提交全局事务时，会放弃之前临时操作的取消权，对应从业务服务的确认操作。

　　因此，对于一个具体的业务服务，TCC分布式事务模型需要业务系统提供三块业务逻辑：

　　初始操作尝试：完成所有业务检查并预留必要的业务资源。

　　确认操作Confirm：不做任何业务检查而实际执行的业务逻辑，只使用Try阶段预留的业务资源。所以，只要Try操作成功，Confirm就一定成功。另外，Confirm 操作需要满足幂等性，以保证一个分布式事务只能成功一次。

　　Cancel操作 Cancel：释放Try阶段预留的业务资源。同样，Cancel操作也需要满足幂等性。

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

　　1.主业务服务：主业务服务是整个业务活动的发起者，服务安排者，负责发起和完成整个业务活动。

　　2.从业务服务：从业务服务是整个业务活动的参与者，负责提供TCC业务操作，实现了初步操作（Try）、确认操作（Confirm）、取消操作（ Cancel) 用于主业务服务调用。

　　3.业务活动管理器：业务活动管理器管理和控制整个业务活动，包括记录和维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并调用所有从业务当业务活动被提交时，服务的Confirm操作会在业务活动被取消时调用从属业务服务的所有Cancel操作。

　　一个完整的TCC分布式事务流程如下：

　　主业务服务首先启动本地事务；主业务服务申请业务活动管理器启动分布式事务主业务活动；然后为了调用次要业务服务，主业务活动首先向业务活动管理器注册次要业务活动，然后调用从业务服务的Try接口；当从业务服务的所有Try接口调用成功后，主业务服务提交本地事务；如果调用失败，则主业务服务回滚本地事务；如果主业务服务提交本地事务，则单独调用TCC模型所有从业务服务的Confirm接口；如果主业务服务回滚本地事务，分别调用Cancel接口；所有从业务服务的确认或取消操作完成后，全局事务结束。

　　TCC模型总结

　　所谓的TCC编程模型也是两阶段提交的变种。TCC 提供了一个编程框架，将整个业务逻辑分为三个部分：Try、Confirm 和Cancel 三个操作。以在线订单为例，在Try阶段会扣除库存，在Confirm阶段更新订单状态。如果订单更新失败，则进入取消阶段，并恢复库存。总之，TCC人为通过代码实现了两阶段提交。不同业务场景编写的代码不同，复杂度也不同。因此，这种模式不能很好地重复使用。

　　分布式事务汇总

　　分布式事务本质上是对多个数据库的事务进行统一控制。按控制强度可分为：不控制、部分控制和完全控制。非控制意味着不引入分布式事务。部分控制是各种变体的两阶段提交，包括上面提到的消息事务+最终一致性，以及TCC模式，完全控制是指完全实现两阶段提交。局部控制的优点是并发量和性能都非常好。缺点是削弱了数据的一致性。完全控制会牺牲性能并保证一致性。最终采用的具体方法取决于业务场景。作为一名技术人员，不能忘记技术服务于业务。不要为了技术而使用技术。针对不同业务的技术选型也是非常重要的能力！

　　您可能还喜欢：阿里巴巴 P8 架构师讲座：4 种分布式 Session 共享技术方案，对比优缺点阿里巴巴 P8 架构师讲座：分布式锁的 3 种实现（数据库、缓存、Zookeeper）：介绍、特性和 5分布式系统全局唯一ID生成方法文章 深入理解“分布式事务” 阿里巴巴P8架构师讲座：单点登录原理、来源、实现、技术方案对比 阿里巴巴P8架构师讲座：分布式事务的原理与技术实现分布式数据库数据一致性