分布式事务二
更多干货
- 分布式事务处理一
- 分布式事务二
- 分布式事务处理三
- 分布式事务四_基于可靠消息的最终一致性
- 分布式事务五_基于可靠消息的最终一致性_异常流程
- 分布式事务六_常规MQ队列
- 分布式事务七_幂等性设计
- 分布式事务八_可靠消息最终一致性方案
- 分布式事务九_基于可靠消息的最终一致性代码
- 分布式事务10_最大努力通知形势
- 柔性事务解决方案：TCC（两阶段型、补偿型）
- 支付宝 分布式事务服务 DTS 一
- 分布式事务服务 DTS二
- 分布式事务服务 DTS三
- 支付宝 分布式事务服务 DTS四
一、BASE理论
- BASE
- BA: Basic Availability 基本业务可用性（支持分区失败）
- S: Soft state 柔性状态（状态允许有短时间不同步，异步）
- E: Eventual consistency 最终一致性（最终数据是一致的，但不是实时一致）
- 原子性（A）与持久性（D）必须根本保障
- 为了可用性、性能与降级服务的需要，只有降低一致性( C ) 与 隔离性( I ) 的要求
- 酸碱平衡(ACID-BASE Balance)
二、CAP定理
定理: 对于共享数据系统，最多只能同时拥有CAP其中的两个，没法三者兼顾。
- 任两者的组合都有其适用场景
- 真实系统应当是ACID与BASE的混合体
- 不同类型的业务可以也应当区别对待
结论：分布式系统中，最重要的是满足业务需求，而不是追求抽象、绝对的系统特性
三、柔性事务
- 两阶段型
- 补偿型
- 异步确保型
- 最大努力通知型
四、柔性事务中的服务模式
- 可查询操作
- 幂等操作
- TCC操作
- 可补偿操作
注：服务模式是柔性事务流程中的特殊操作实现（实现上对应业务服务要提供相应模式的功能接口），还不算是某一种柔性事务解决方案。
五、柔性事务中的服务模式：可查询操作
服务操作的可标识性
- 服务操作具有全局唯一标识
- 可以使用业务单据号（如订单号）
- 或者使用系统分配的操作流水号（如支付记录流水号）
- 或者使用操作资源的组合组合标识（如商户号+商户订单号）
- 操作有唯一的、确定的时间(约定以谁的时间为准)
单笔查询
- 使用全局唯一的服务操作标识，查询操作执行结果
- 注意状态判断，小心“处理中”的状态
批量查询
- 使用时间区段与(或)一组服务操作的标识，查询一批操作执行结果
六、柔性事务中的服务模式：幂等操作
幂等性（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操作，其实也可以看作是补偿操作）
九、待续
分布式事务三