关于分布式事务的读书笔记

事务

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

ACID:

Atomcity:原子性

Consistency:一致性

Isolation:隔离性

Durability:持久性

难点:

1.高度并发

2.资源分布

3.大时间跨度

 

本地事务

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

优点:

1.支持严格的ACID属性

2.可靠

3.高效

4.状态可以只在资源管理器中维护

5.应用编程模型简单(在框架或平台的支持)

局限:

1.不具备分布式事务处理能力

2.隔离的最小单位由资源管理器决定,如数据库中的一条记录

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

4.本地事务不涉及多个数据源

 

刚性事务

全局事务(DTP模型)--标准的分布事务

全局事务:

事务由全局事务管理器全局管理

事务管理器:

管理全局事务状态与参与的资源,协同资源的一致提交/回滚

TX协议:

应用或应用服务器与事务管理器的接口

XA协议:

全局事务管理器与资源管理的接口

1.AP(Application Program):也就是应用程序, 可以理解为使用 DTP 的程序;
2.RM(Resource Manager):资源管理器(这里 可以是一个 DBMS,或者消息服务器管理系统) 应用程序通过资源管理器对资源进行控制,资 源必须实现 XA 定义的接口;
3.TM(Transaction Manager):事务管理器,负 责协调和管理事务,提供给 AP 应用程序编程 接口以及管理资源管理器。
4.事务管理器控制着全局事务,管理事务生命周 期,并协调资源。资源管理器负责控制和管理 实际资源。

X/Open 组织(即现在的 Open Group )定义了分布式事务处理模型。 X/Open DTP 模型( 1994 )包括应用程序( AP )、事务管理器( TM )、资源管理器( RM )、通信资源管理器( CRM )四部分。一般,常见的事务管理器( TM )是交易中间件,常见的资源管理器( RM )是数据库,常见的通信资源管理器( CRM )是消息中间件。 通常把一个数据库内部的事务处理,如对多个表的操作,作为本地事务看待。数据库的事务处理对象是本地事务,而分布式事务处理的对象是全局事务。实现方式一
• 通过业务操作本身实现幂等性

 实现方式二
• 系统缓存所有请求与处理结果
• 检测到重复请求之后,自动返回之前的处理结果 

 

3. TCC操作

Try: 尝试执行业务
• 完成所有业务检查(一致性)
• 预留必须业务资源(准隔离性)

 Confirm:确认执行业务
• 真正执行业务
• 不作任何业务检查
• 只使用Try阶段预留的业务资源

• Confirm操作要满足幂等性

 Cancel: 取消执行业务
• 释放Try阶段预留的业务资源

• Cancel操作要满足幂等性 

 

与2PC协议比较
• 位于业务服务层而非资源层,如jta是服务于资源层
• 没有单独的准备(Prepare)阶段,

Try操作兼备资源操作与准备能力

• Try操作可以灵活选择业务资源的

锁定粒度(以业务定粒度)

• 较高开发成本 

 

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

其实TCC操作也属于两阶段型操作。 

 

4. 可补偿操作 

do: 真正执行业务
• 完成业务处理
• 业务执行结果外部可见

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

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

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

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

 

柔性事务的解决方案:

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

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

用到的服务模式
• 可查询操作、幂等操作

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

 

TCC(两阶段型、补偿型) 

实现
•一个完整的业务活动由一个主业务服务与若干从业务服务组成
•主业务服务负责发起并完成整个业务活动
•从业务服务提供TCC型业务操作
•业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在业务活动提交时确认所有的TCC型操作的confirm操作,在业务活动取消 时调用所有TCC型操作的cancel操作
成本
• 实现TCC操作的成本
• 业务活动结束时confirm或cancel操作的执行成本
• 业务活动日志成本
适用范围
• 强隔离性、严格一致性要求的业务活动
• 适用于执行时间较短的业务(比如处理账户、收费等业务) 

用到的服务模式
• TCC操作、幂等操作、可补偿操作、可查询操作

方案特点

• 不与具体的服务框架耦合(在RPC架构中通用)

• 位于业务服务层,而非资源层

• 可以灵活选择业务资源的锁定粒度

• TCC里对每个服务资源操作的是本地事务,数据被lock的时间短,可扩展性好(可以说是为独立部署的 SOA服务而设计的) 

 

柔性事务解决方案:最大努力通知(定期校对)

实现
• 业务活动的主动方,在完成业务处理之后,向业务活动的被动方发送消息,
允许消息丢失。
• 业务活动的被动方根据定时策略,向业务活动主动方查询,恢复丢失的业 务消息。
 约束
• 被动方的处理结果不影响主动方的处理结果  成本
• 业务查询与校对系统的建设成本
 适用范围
• 对业务最终一致性的时间敏感度低
• 跨企业的业务活动

用到的服务模式

• 可查询操作

 方案特点
• 业务活动的主动方在完成业务处理后,向业务活动被动方发送通知消息(允许消息丢失)
• 主动方可以设置时间阶梯型通知规则,在通知失败后按规则重复通知,直到通知N次后不再通知 • 主动方提供校对查询接口给被动方按需校对查询,用于恢复丢失的业务消息

 行业应用案例
• 银行通知、商户通知等(各大交易业务平台间的商户通知:多次通知、查询校对、对账文件) 

 

 

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

• 刚性事务

- 全局事务(标准的分布式事务)

• 柔性事务

- 可靠消息最终一致(异步确何型)
- TCC (两阶段型、补偿型)
- 最大努力通知(非可靠消息 、定期校对)

- 纯补偿型(略) 

 

 

参考http://www.linkedkeeper.com/detail/blog.action?bid=1013

posted @ 2019-04-09 17:24  加肥猫咪  阅读(...)  评论(... 编辑 收藏