事务专题（三）——分布式事务

2018-11-06 本文已影响0人 BugBean

分布式事务是什么

A distributed transaction is a database transaction in which two or more network hosts are involved.

翻译过来就是——分布式事务是涉及两个或多个网络主机的数据库事务。关于数据库事务可以参考这篇文章。
举个栗子：

充值时序图.png

创建订单事务、记账事务和修改订单状态事务是3个独立的本地事务，但这3个事务在业务上应当要保证是一个原子操作，现在假设创建订单和记账成功之后，修改订单状态失败，那么记账事务要回滚，由于账户DB和订单DB是不同的网络主机，所以本地事务解决不了这个问题。

标准DTP模型——全局事务

全局事务定义了三个组件： AP，TM，RM
AP(Application Program)：也就是应用程序，可以理解为使用DTP的程序
RM(Resource Manager)：资源管理器（这里可以是一个 DBMS，或者消息服务器管理系统）应用程序通过资源管理器对资源进行控制，资源(数据库、消息队列等)必须实现 XA 定义的接口
TM(Transaction Manager)：事务管理器，负责协调和管理全局事务及其生命周期，提供给 AP 应用程序编程接口（TX协议）以及管理资源管理器

其中，AP 可以和TM 以及 RM 通信，TM 和 RM 互相之间可以通信，DTP模型里面定义了XA接口，TM 和 RM 通过XA接口进行双向通信

其中上图中的7、8、9、10步骤应用了两阶段提交算法来保证全局事务的一致性

两阶段提交

可以看到两阶段提交是非常消耗性能的，数据被Lock的时间跨整个事务，直到全局事务结束。

总的来说，全局事务的优点是能保证严格的ACID，缺点是效率非常低。

CAP定理

标准DTP模型会极大地影响整个分布式系统的性能，应付不了现代互联网系统的需求。

那么有没有一种既能保证整个全局事务的ACID，而且效率又高的分布式事务解决方案呢？我们先来看看大名鼎鼎的CAP定理

CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：^[1]^[2]

一致性（Consistency）（等同于所有节点访问同一份最新的数据副本）
可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择^[3]。）

所以一种既能保证整个全局事务的ACID，而且效率又高的分布式事务解决方案是不存在的。标准DTP模型也是牺牲了可用性来保证一致性。在分布式系统中，分区容错性和可用性的优先级是高于一致性的，那么我们的思路应该是牺牲一致性来保证高可用。

BASE理论

BASE理论是用来对CAP定理进行进一步扩充的。BASE理论指的是：

Basically Available（基本可用）
Soft state（软状态）
Eventually consistent（最终一致性）

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

柔性事务

柔性事务就是基于BASE理论，保证数据的最终一致性——系统中的所有数据副本经过一段时间后，最终能达到一致的状态。

服务模式

服务模式是柔性事务流程中的特殊操作实现(实现上对应业务服务要提供相应模式的功能接口)，还不算是某一种柔性事务解决方案。

可查询操作

服务操作的可标识性

服务操作具有全局唯一标识
– 可以使用业务单据号(如订单号)
– 或者使用系统分配的操作流水号(如支付记录流水号)
– 或者使用操作资源的组合组合标识(如商户号+商户订单号)
操作有唯一的、确定的时间(约定以谁的时间为准)

单笔查询

使用全局唯一的服务操作标识，查询操作执行结果 • 注意状态判断，小心“处理中”的状态

批量查询
• 使用时间区段与(或)一组服务操作的标识，查询一批操作执行结果

幂等操作

幂等性(Idempotenty)
f(f(x)) = f(x)

幂等操作

重复调用多次产生的业务结果与调用一次产生的业务结果相同

实现方式一

通过业务操作本身实现幂等性

实现方式二

系统缓存所有请求与处理结果
检测到重复请求之后，自动返回之前的处理结果

TCC操作

Try: 尝试执行业务

完成所有业务检查(一致性)
预留必须业务资源(准隔离性)

Confirm:确认执行业务

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

Cancel: 取消执行业务

释放Try阶段预留的业务资源
Cancel操作要满足幂等性

与2PC协议比较

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

误区:很多人把两阶段型操作等同于两阶段提交协议2PC操作。
其实TCC操作也属于两阶段型操作。

可补偿操作

do: 真正执行业务

完成业务处理
业务执行结果外部可见

compensate:业务补偿

抵销(或部分抵销)正向业务操作的业务结果
补偿操作满足幂等性

约束

补偿在业务上可行
由于业务执行结果未隔离、或者补偿不完整带来的风险与成本可控

(TCC操作中的Confirm操作和Cancel操作，其实也可以看作是补偿操作)

解决方案

可靠消息最终一致（异步确保型）

实现

业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送

消息

业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效

约束

被动方的处理结果不影响主动方的处理结果，被动方的消息处理操作是幂等操作

成本

可靠消息系统建设成本
一次消息发送需要两次请求，业务处理服务需实现消息状态回查接口

优点、适用范围

消息数据独立存储、独立伸缩，降低业务系统与消息系统间的耦合
对最终一致性时间敏感度较高，降低业务被动方实现成本

用到的服务模式

可查询操作、幂等操作

方案特点

兼容所有实现JMS标准的MQ中间件(本教程中实现的方案)
确保业务数据可靠的前提下，实现业务数据的最终一致(理想状态下基本是准实时一致)

改造后的充值流程：

可靠消息服务

那么消息发送一致性^[1]如何保障，先来看看上图的实现细节

总结起来就是

消息发送一致性的正向流程

消息发送一致性的异常处理

TCC(两阶段型、补偿型)

实现

一个完整的业务活动由一个主业务服务与若干从业务服务组成
主业务服务负责发起并完成整个业务活动
从业务服务提供TCC型业务操作
业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作

成本

实现TCC操作的成本
业务活动结束时confirm或cancel操作的执行成本
业务活动日志成本

适用范围

强隔离性、严格一致性要求的业务活动
适用于执行时间较短的业务(比如处理账户、收费等业务)