分布式事务解决方案(总览)

原帖

https://blog.csdn.net/wuzhiwei549/article/details/79787866

下面的使用

https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

总览

        本系列针对分布式事务提出三种解决方案：可靠消息最终一致性、最大努力通知、TCC。 每种方案分为上下两篇，上篇为原理概述，下篇为具体实现。

        本篇是对本地事务和分布式事务的特性理解分析，喜欢的多多pick！

事务概念

 

本地事务

 

 在单个数据库的本地并且限制在单 个进程内的事务

 本地事务不涉及多个数据来源

 

 

全局事务（DTP）

 

XA是由X/Open组织提出的分布式事务的规范。 XA规范主要定义了(全局)事务管理器(TM)和(局 部)资源管理器(RM)之间的接口。主流的关系型 数据库产品都是实现了XA接口的。
 XA接口是双向的系统接口，在事务管理器 （TM）以及一个或多个资源管理器（RM）之 间形成通信桥梁。
 XA之所以需要引入事务管理器是因为，在分布 式系统中，从理论上讲两台机器理论上无法达 到一致的状态，需要引入一个单点进行协调。
 由全局事务管理器管理和协调的事务，可以跨 越多个资源（如数据库或JMS队列）和进程。 全局事务管理器一般使用 XA 二阶段提交协议 与数据库进行交互。
详解请跳转 XA 分布式事务原理
 

两阶段提交(Two Phase Commit)

 

 两阶段提交协议（Two-phase commit protocol） 是XA用于在全局事务中协调多个资源的机制。
 TM和RM间采取两阶段提交(Two Phase Commit) 的方案来解决一致性问题。
 两阶段提交需要一个协调者（TM）来掌控所有参与 者节点（RM）的操作结果并且指引这些节点是否需 要最终提交。
 

 JTA（Java Transaction API）：面向应用、应用服务器与资 源管理器的高层事务接口。
 JTS（Java Transaction Service）：JTA事务管理器的实现标 准，向上支持JTA，向下通过CORBA OTS实现跨事务域的互 操作性。
 EJB：基于组件的应用编程模型，通过声明式事务管理进一步 简化事务应用的编程。
 优点 • 简单一致的编程模型 • 跨域分布处理的ACID保证
 局限 • DTP模型本身的局限

 

标准分布式事务解决方案的利弊
 优点：严格的ACID
 缺点：效率非常低（微服务架构下已不太适用）
• 全局事务方式下，全局事务管理器（TM）通过XA接口使用二阶段提交协议（ 2PC ）与资源层（如数据 库）进行交互。使用全局事务，数据被Lock的时间跨整个事务，直到全局事务结束。
• 2PC 是反可伸缩模式，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样， 当业务规模越来越大的情况下，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。
• 与本地事务相比，XA 协议的系统开销相当大，因而应当慎重考虑是否确实需要分布式事务。而且只有 支持 XA 协议的资源才能参与分布式事务。

 

服务模式

 可查询操作
 服务操作的可标识性
• 服务操作具有全局唯一标识 – 可以使用业务单据号（如订单号） – 或者使用系统分配的操作流水号（如支付记录流水号） – 或者使用操作资源的组合组合标识（如商户号+商户订单号）
• 操作有唯一的、确定的时间(约定以谁的时间为准)
 单笔查询
• 使用全局唯一的服务操作标识，查询操作执行结果
• 注意状态判断，小心“处理中”的状态
 批量查询
• 使用时间区段与(或)一组服务操作的标识，查询一批操作执行结果

 幂等操作
 幂等性（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操作，其实也可以看作是补偿操作）

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

可靠消息最终一致性方案
 用到的服务模式
• 可查询操作、幂等操作
 方案特点
• 兼容所有实现JMS标准的MQ中间件
• 确保业务数据可靠的前提下，实现业务数据的最终一致（理想状态下基本是准实时一致）
 行业应用案例
• 支付宝、eBay（BASE）、去哪儿……
对应支付系统会计异步记账业务
银行通知结果信息存储与驱动订单处理
 

 实现
• 业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。业务处理服务在业务事务提交后，向实时消息服务确认 发送。只有在得到确认发送指令后，实时消息服务才真正发送
 消息
• 业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期 找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根 据消息ID或消息内容确定该消息是否有效
 约束
• 被动方的处理结果不影响主动方的处理结果， 被动方的消息处理操作是幂等操作
 成本
• 可靠消息系统建设成本
• 一次消息发送需要两次请求，业务处理服务需实现消息状态回查接口
 优点、适用范围
• 消息数据独立存储、独立伸缩，降低业务系统与消息系统间的耦合
• 对最终一致性时间敏感度较高，降低业务被动方实现成本
1.独立部署，独立伸缩（扩展性）
2.兼容所有实现JMS标准的MQ中间件
3.降低业务系统与消息系统间的耦合性
4.可实现数据可靠的前提下确保最终一致性
 

 TCC方案
 用到的服务模式
• TCC操作、幂等操作、可补偿操作、可查询操作
 方案特点
• 不与具体的服务框架耦合（在RPC架构中通用）
• 位于业务服务层，而非资源层 • 可以灵活选择业务资源的锁定粒度
• TCC里对每个服务资源操作的是本地事务，数据被lock的时间短，可扩展性好（可以说是为独立部署的 SOA服务而设计的）
 行业应用案例
• 支付宝XTS（蚂蚁金融云的分布式事务服务DTS）
 

 

 实现
• 一个完整的业务活动由一个主业务服务与若干从业务服务组成
• 主业务服务负责发起并完成整个业务活动
• 从业务服务提供TCC型业务操作
• 业务活动管理器控制业务活动的一致性，它登记业务活动中的操作， 并在 业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消 时调用所有TCC型操作的cancel操作
 成本
• 实现TCC操作的成本
• 业务活动结束时confirm或cancel操作的执行成本
• 业务活动日志成本
 优点、适用范围
• 强隔离性、严格一致性要求的业务活动 • 适用于执行时间较短的业务（比如处理账户、收费等业务）
1.不与具体的服务框架耦合
2.位于业务服务层，而非资源层
3.可以灵活选择业务资源的锁定粒度
4.适用于强隔离性，严格一致性要求的业务场景
5..适用于业务执行时间较短的业务

最大努力通知型方案
 用到的服务模式
• 可查询操作
 方案特点
• 业务活动的主动方在完成业务处理后，向业务活动被动方发送通知消息（允许消息丢失）
• 主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知N次后不再通知
• 主动方提供校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息
 行业应用案例
• 银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对账文件）
 

 实现
• 业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息， 允许消息丢失。
• 业务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业 务消息。
 约束
• 被动方的处理结果不影响主动方的处理结果
 成本
• 业务查询与校对系统的建设成本
 适用范围
• 对业务最终一致性的时间敏感度低 • 跨企业的业务活动
按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对
---------------------