分布式事务解决方案笔记 Segment2¶
分布式事务解决方案介绍¶
事务¶
由一组操作构成的可靠、独立的工作单元
ACID:
- Atomicity(原子性)
- Consistency(一致性)
- Isolation(隔离性)
- Durability(持久性)
难点:
- 高度并发
- 资源分布
- 大时间跨度
本地事务¶
事务由资源管理器(如DBMS)本地管理
- 在单个数据库的本地,并且限制在单个进程内的事务
- 本地事务不涉及多个数据来源
优点
- 支持严格的ACID属性
- 可靠
- 高效
- 状态可以只在资源管理器中维护
- 应用编程模型简单(在框架或平台的支持)
局限
- 不具备分布事务处理能力
- 隔离的最小单元由资源管理器决定,如数据库中的一条记录
全局事务(DTP模型)——标准分布式事务¶
dtpStandard-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)¶
twoPhaseCommit-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定理¶
CAP-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操作也属于两阶段型操作。
可补偿操作¶
doCompensate-min
- do: 真正执行业务
- 完成业务处理
- 业务执行结果外部可见
- compensate:业务补偿
- 抵销(或部分抵销)正向业务操作的业务结果
- 补偿操作满足幂等性
- 约束
- 补偿在业务上可行
- 由于业务执行结果未隔离、或者补偿不完整带来的风险与成本可控
(TCC操作中的Confirm操作和Cancel操作,其实也可以看作是补偿操作)
柔性事务解决方案¶
可靠消息最终一致(异步确保型)¶
distributedTransactionFinal-min
- 实现
- 业务处理服务在业务事务提交前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不真正发送。业务处理服务在业务事务提交后,向实时消息服务确认发送。只有在得到确认发送指令后,实时消息服务才真正发送
- 消息
- 业务处理服务在业务事务回滚后,向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或回滚发送的消息,向业务处理服务询问消息状态,业务处理服务根据消息ID或消息内容确定该消息是否有效
- 约束
- 被动方的处理结果不影响主动方的处理结果,被动方的消息处理操作是幂等操作
- 成本
- 可靠消息系统建设成本
- 一次消息发送需要两次请求,业务处理服务需实现消息状态回查接口
- 优点、适用范围
- 消息数据独立存储、独立伸缩,降低业务系统与消息系统间的耦合
- 对最终一致性时间敏感度较高,降低业务被动方实现成本
- 用到的服务模式
- 可查询操作、幂等操作
- 方案特点
- 兼容所有实现JMS标准的MQ中间件(本教程中实现的方案)
- 确保业务数据可靠的前提下,实现业务数据的最终一致(理想状态下基本是准实时一致)
- 行业应用案例
- 支付宝、eBay(BASE)、去哪儿……
TCC(两阶段型、补偿型)¶
distributedTransactionTCC-min
- 实现
- 一个完整的业务活动由一个主业务服务与若干从业务服务组成
- 主业务服务负责发起并完成整个业务活动
- 从业务服务提供TCC型业务操作
- 业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在业务活动提交时确认所有的TCC型操作的confirm操作,在业务活动取消时调用所有TCC型操作的cancel操作
- 成本
- 实现TCC操作的成本
- 业务活动结束时confirm或cancel操作的执行成本
- 业务活动日志成本
- 适用范围
- 强隔离性、严格一致性要求的业务活动
- 适用于执行时间较短的业务(比如处理账户、收费等业务)
- 用到的服务模式
- TCC操作、幂等操作、可补偿操作、可查询操作
- 方案特点
- 不与具体的服务框架耦合(在RPC架构中通用)
- 位于业务服务层,而非资源层
- 可以灵活选择业务资源的锁定粒度
- TCC里对每个服务资源操作的是本地事务,数据被lock的时间短,可扩展性好(可以说是为独立部署的SOA服务而设计的)
- 行业应用案例
- 支付宝XTS(蚂蚁金融云的分布式事务服务DTS)
最大努力通知(定期校对)¶
distributedTransactionMax-min
- 实现
- 业务活动的主动方,在完成业务处理之后,向业务活动的被动方发送消息,允许消息丢失。
- 业务活动的被动方根据定时策略,向业务活动主动方查询,恢复丢失的业务消息。
- 约束
- 被动方的处理结果不影响主动方的处理结果
- 成本
- 业务查询与校对系统的建设成本
- 适用范围
- 对业务最终一致性的时间敏感度低
- 跨企业的业务活动
- 用到的服务模式
- 可查询操作
- 方案特点
- 业务活动的主动方在完成业务处理后,向业务活动被动方发送通知消息(允许消息丢失)
- 主动方可以设置时间阶梯型通知规则,在通知失败后按规则重复通知,直到通知N次后不再通知
- 主动方提供校对查询接口给被动方按需校对查询,用于恢复丢失的业务消息
- 行业应用案例
- 银行通知、商户通知等(各大交易业务平台间的商户通知:多次通知、查询校对、对账文件)