分布式事务三

分布式事务处理三

更多干货

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

柔性事务解决方案：可靠消息最终一致（异步确保型）

实现

• 业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送

消息

• 业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效

约束

• 被动方的处理结果不影响主动方的处理结果， 被动方的消息处理操作是幂等操作

成本

• 可靠消息系统建设成本
• 一次消息发送需要两次请求，业务处理服务需实现消息状态回查接口

优点、适用范围

• 消息数据独立存储、独立伸缩，降低业务系统与消息系统间的耦合
• 对最终一致性时间敏感度较高，降低业务被动方实现成本 

用到的服务模式

• 可查询操作、幂等操作

方案特点

• 兼容所有实现JMS标准的MQ中间件
• 确保业务数据可靠的前提下，实现业务数据的最终一致（理想状态下基本是准实时一致）

行业应用案例

• 支付宝、eBay（BASE）、去哪儿

柔性事务解决方案：TCC（两阶段型、补偿型）

实现

• 一个完整的业务活动由一个主业务服务与若干从业务服务组成
• 主业务服务负责发起并完成整个业务活动
• 从业务服务提供TCC型业务操作
• 业务活动管理器控制业务活动的一致性，它登记业务活动中的操作， 并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作

成本

• 实现TCC操作的成本
• 业务活动结束时confirm或cancel操作的执行成本
• 业务活动日志成本

适用范围

• 强隔离性、严格一致性要求的业务活动
• 适用于执行时间较短的业务（比如处理账户、收费等业务）

用到的服务模式

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

方案特点

• 不与具体的服务框架耦合（在RPC架构中通用）
• 位于业务服务层，而非资源层
• 可以灵活选择业务资源的锁定粒度
• TCC里对每个服务资源操作的是本地事务，数据被lock的时间短，可扩展性好（可以说是为独立部署的SOA服务而设计的）

行业应用案例

• 支付宝XTS（蚂蚁金融云的分布式事务服务DTS）

柔性事务解决方案：最大努力通知（定期校对）

实现

• 业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失。
• 业务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业务消息。

约束

• 被动方的处理结果不影响主动方的处理结果

成本

• 业务查询与校对系统的建设成本

适用范围

• 对业务最终一致性的时间敏感度低
• 跨企业的业务活动

用到的服务模式

• 可查询操作

方案特点

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

行业应用案例

• 银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对账文件）

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

1. 刚性事务

• 全局事务（标准的分布式事务）

2. 柔性事务

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

待续

分布式事务处理四