分布式事务解决方案笔记 Segment2

分布式事务解决方案介绍

事务

由一组操作构成的可靠独立的工作单元

ACID:

  • Atomicity(原子性)
  • Consistency(一致性)
  • Isolation(隔离性)
  • Durability(持久性)

难点:

  • 高度并发
  • 资源分布
  • 大时间跨度

本地事务

事务由资源管理器(如DBMS)本地管理

  • 在单个数据库的本地,并且限制在单个进程内的事务
  • 本地事务不涉及多个数据来源

优点

  • 支持严格的ACID属性
  • 可靠
  • 高效
  • 状态可以只在资源管理器中维护
  • 应用编程模型简单(在框架或平台的支持)

局限

  • 不具备分布事务处理能力
  • 隔离的最小单元由资源管理器决定,如数据库中的一条记录

全局事务(DTP模型)——标准分布式事务

https://s0.wailian.download/2019/01/23/dtpStandard-min.pngdtpStandard-min

  • 全局事务:事务由全局事务管理器全局管理
  • 事务管理器:管理全局事务状态与参与的资源,协同资源的一致提交/回滚
  • TX协议:应用或应用服务器与事务管理器的接口
  • XA协议:全局事务管理器与资源管理器的接口
    • AP(Application Program):也就是应用程序,可以理解为使用DTP的程序。
    • RM(Resource Manager):资源管理器(这里可以是一个DBMS,或者消息服务器管理系统)应用程序通过资源管理器对资源进行控制,资源必须实现XA定义的接口。
    • TM(Transaction Manager):事务管理器,负责协调和管理事务,提供给AP应用程序编程接口以及管理资源管理器。
    • 事务管理器控制着全局事务,管理事务生命周期,并协调资源。资源管理器负责控制和管理实际资源。
    • XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接口。主流的关系型数据库产品都是实现了XA接口的。
    • XA接口是双向的系统接口,在事务管理器(TM)以及一个或多个资源管理器(RM)之间形成通信桥梁。
    • XA之所以需要引入事务管理器是因为,在分布式系统中,从理论,上讲两台机器理论上无法达到一致的状态,需要引入一个单点进行协调。
    • 由全局事务管理器管理和协调的事务,可以跨越多个资源(如数据库或JMS队列)和进程。全局事务管理器一般使用XA二阶段提交协议与数据库进行交互。

两阶段提交(Two Phase Commit)

https://s0.wailian.download/2019/01/23/twoPhaseCommit-min.pngtwoPhaseCommit-min

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

准备操作与ACID

  • A:准备后,仍可提交与回滚
  • C:准备时,一致性检查必须OK
  • I:准备后,事务结果仍然只在事务内可见
  • D:准备后,事务结果已经持久

局限

  • 协议成本(准备操作是一定必须的吗)
  • 准备阶段的持久成本
  • 全局事务状态的持久成本
  • 潜在故障点多带来的脆弱性
  • 准备后,提交前的故障引发一系列隔离与恢复难题

JavaEE平台中的分布式事务实现

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

标准分布式事务解决方案的利弊

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

BASE理论

  • BASE
    • BA:Basic Availability基本业务可用性(支持分区失败)
    • S:Soft state柔性状态(状态允许有短时间不同步,异步)
    • E:Eventual consistency最终一致性(最终数据是一致的,但不是实时一致)
  • 原子性(A)与持久性(D)必须根本保障
  • 为了可用性、性能与降级服务的需要,只有降低一致性(C)与隔离性(I)的要求
  • 酸碱平衡(ACID-BASE Balance)

CAP定理

https://s0.wailian.download/2019/01/23/CAP-min.pngCAP-min

定理:对于共享数据系统,最多只能同时拥有CAP其中的两个,没法三者兼顾。

  • 任两者的组合都有其适用场景
  • 真实系统应当是ACID与BASE的混合体
  • 不同类型的业务可以也应当区别对待

结论:分布式系统中,最重要的是满足业务需求,而不是追求抽象、绝对的系统特性。

柔性事务中的服务模式

  • 可查询操作
  • 幂等操作
  • TCC操作
  • 可补偿操作

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

可查询操作

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

幂等操作

  • 幂等性(Idempotenty):f(f(x)) = f(x)
  • 幂等操作:重复调用多次产生的业务结果与调用一次产生的业务结果相同
  • 实现方式一
    • 通过业务操作本身实现幂等性
  • 实现方式二
    • 系统缓存所有请求与处理结果
    • 检测到重复请求之后,自动返回之前的处理结果

TCC操作

  • Try:尝试执行业务
    • 完成所有业务检查(一致性)
    • 预留必须业务资源(准隔离性)
  • Confirm:确认执行业务
    • 真正执行业务
    • 不作任何业务检查
    • 只使用Try阶段预留的业务资源
    • Confirm操作要满足幂等性
  • Cancel:取消执行业务
    • 释放Try阶段预留的业务资源
    • Cancel操作要满足幂等性
  • 与2PC协议比较
    • 位于业务服务层而非资源层
    • 没有单独的准备(Prepare)阶段,Try操作兼备资源操作与准备能力
    • Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度)
    • 较高开发成本

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

可补偿操作

https://s0.wailian.download/2019/01/23/doCompensate-min.pngdoCompensate-min

  • do: 真正执行业务
    • 完成业务处理
    • 业务执行结果外部可见
  • compensate:业务补偿
    • 抵销(或部分抵销)正向业务操作的业务结果
    • 补偿操作满足幂等性
  • 约束
    • 补偿在业务上可行
    • 由于业务执行结果未隔离、或者补偿不完整带来的风险与成本可控

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

柔性事务解决方案

可靠消息最终一致(异步确保型)

https://s0.wailian.download/2019/01/08/distributedTransactionFinal-min.pngdistributedTransactionFinal-min

  • 实现
    • 业务处理服务在业务事务提交前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不真正发送。业务处理服务在业务事务提交后,向实时消息服务确认发送。只有在得到确认发送指令后,实时消息服务才真正发送
  • 消息
    • 业务处理服务在业务事务回滚后,向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或回滚发送的消息,向业务处理服务询问消息状态,业务处理服务根据消息ID或消息内容确定该消息是否有效
  • 约束
    • 被动方的处理结果不影响主动方的处理结果,被动方的消息处理操作是幂等操作
  • 成本
    • 可靠消息系统建设成本
    • 一次消息发送需要两次请求,业务处理服务需实现消息状态回查接口
  • 优点、适用范围
    • 消息数据独立存储、独立伸缩,降低业务系统与消息系统间的耦合
    • 对最终一致性时间敏感度较高,降低业务被动方实现成本
  • 用到的服务模式
    • 可查询操作、幂等操作
  • 方案特点
    • 兼容所有实现JMS标准的MQ中间件(本教程中实现的方案)
    • 确保业务数据可靠的前提下,实现业务数据的最终一致(理想状态下基本是准实时一致)
  • 行业应用案例
    • 支付宝、eBay(BASE)、去哪儿……

TCC(两阶段型、补偿型)

https://s0.wailian.download/2019/01/08/distributedTransactionTCC-min.pngdistributedTransactionTCC-min

  • 实现
    • 一个完整的业务活动由一个主业务服务与若干从业务服务组成
    • 主业务服务负责发起并完成整个业务活动
    • 从业务服务提供TCC型业务操作
    • 业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在业务活动提交时确认所有的TCC型操作的confirm操作,在业务活动取消时调用所有TCC型操作的cancel操作
  • 成本
    • 实现TCC操作的成本
    • 业务活动结束时confirm或cancel操作的执行成本
    • 业务活动日志成本
  • 适用范围
    • 强隔离性、严格一致性要求的业务活动
    • 适用于执行时间较短的业务(比如处理账户、收费等业务)
  • 用到的服务模式
    • TCC操作、幂等操作、可补偿操作、可查询操作
  • 方案特点
    • 不与具体的服务框架耦合(在RPC架构中通用)
    • 位于业务服务层,而非资源层
    • 可以灵活选择业务资源的锁定粒度
    • TCC里对每个服务资源操作的是本地事务,数据被lock的时间短,可扩展性好(可以说是为独立部署的SOA服务而设计的)
  • 行业应用案例
    • 支付宝XTS(蚂蚁金融云的分布式事务服务DTS)

最大努力通知(定期校对)

https://s0.wailian.download/2019/01/08/distributedTransactionMax-min.pngdistributedTransactionMax-min

  • 实现
    • 业务活动的主动方,在完成业务处理之后,向业务活动的被动方发送消息,允许消息丢失。
    • 业务活动的被动方根据定时策略,向业务活动主动方查询,恢复丢失的业务消息。
  • 约束
    • 被动方的处理结果不影响主动方的处理结果
  • 成本
    • 业务查询与校对系统的建设成本
  • 适用范围
    • 对业务最终一致性的时间敏感度低
    • 跨企业的业务活动
  • 用到的服务模式
    • 可查询操作
  • 方案特点
    • 业务活动的主动方在完成业务处理后,向业务活动被动方发送通知消息(允许消息丢失)
    • 主动方可以设置时间阶梯型通知规则,在通知失败后按规则重复通知,直到通知N次后不再通知
    • 主动方提供校对查询接口给被动方按需校对查询,用于恢复丢失的业务消息
  • 行业应用案例
    • 银行通知、商户通知等(各大交易业务平台间的商户通知:多次通知、查询校对、对账文件)

总结

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

  • 刚性事务
    • 全局事务(标准的分布式事务)
  • 柔性事务
    • 可靠消息最终一致(异步确何型)
    • TCC(两阶段型、补偿型)
    • 最大努力通知(非可靠消息、定期校对)
    • 纯补偿型(略)