分布式事务二

分布式事务二

更多干货

• 分布式事务处理一
• 分布式事务二
• 分布式事务处理三
• 分布式事务四_基于可靠消息的最终一致性
• 分布式事务五_基于可靠消息的最终一致性_异常流程
• 分布式事务六_常规MQ队列
• 分布式事务七_幂等性设计
• 分布式事务八_可靠消息最终一致性方案
• 分布式事务九_基于可靠消息的最终一致性代码
• 分布式事务10_最大努力通知形势
• 柔性事务解决方案：TCC（两阶段型、补偿型）
• 支付宝 分布式事务服务 DTS 一
• 分布式事务服务 DTS二
• 分布式事务服务 DTS三
• 支付宝 分布式事务服务 DTS四

一、BASE理论

• BASE

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

二、CAP定理

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

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

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

三、柔性事务

1. 两阶段型
2. 补偿型
3. 异步确保型
4. 最大努力通知型

四、柔性事务中的服务模式

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

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

五、柔性事务中的服务模式：可查询操作

服务操作的可标识性

• 服务操作具有全局唯一标识

1. 可以使用业务单据号（如订单号）
2. 或者使用系统分配的操作流水号（如支付记录流水号）
3. 或者使用操作资源的组合组合标识（如商户号+商户订单号）

• 操作有唯一的、确定的时间(约定以谁的时间为准)

单笔查询

• 使用全局唯一的服务操作标识，查询操作执行结果
• 注意状态判断，小心“处理中”的状态

批量查询

• 使用时间区段与(或)一组服务操作的标识，查询一批操作执行结果

六、柔性事务中的服务模式：幂等操作

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

九、待续

分布式事务三