关于分布式事务的读书笔记
事务
由一组操作构成的可靠、独立的工作单元
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 (两阶段型、补偿型)
- 最大努力通知(非可靠消息 、定期校对)
- 纯补偿型(略)
