分布式事务是什么
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操作的执行成本
- 业务活动日志成本
适用范围
- 强隔离性、严格一致性要求的业务活动
- 适用于执行时间较短的业务(比如处理账户、收费等业务)
用到的服务模式
- TCC操作、幂等操作、可补偿操作、可查询操作
方案特点
- 不与具体的服务框架耦合(在RPC架构中通用)
- 位于业务服务层，而非资源层
- 可以灵活选择业务资源的锁定粒度
- TCC里对每个服务资源操作的是本地事务，数据被lock的时间短，可扩展性好(可以说是为独立部署的 SOA服务而设计的)
参考资料:
-
是指产生消息的业务动作与消息发送的一致，也就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去，否则就丢消息 ↩
网友评论