分布式事务

最大努力通知型

最大努力通知型( Best-effort delivery)，适用于一些最终一致性时间敏感度低的业务，一般用于与外部系统接口交互，当调用外部系统接口成功之后，只是外部系统接收请求成功，并不代表外部系统处理完，因此后续接口处理完之后再异步通知处理结果。
典型的使用场景：如第三方支付结果通知。
最大努力通知型有以下特点：

• 不可靠消息
  外部系统接口在完成业务处理之后，向接口调用方发送消息，直到通知N次后不再通知，允许消息丢失(不可靠消息)。

• 定期校对
  外部系统接口调用方，根据定时策略，向外部系统查询(外部系统提供查询接口)，恢复丢失的业务消息。

以短信发送平台为例：

image.png

TCC两阶段补偿型

TCC是Try-Confirm-Cancel的简称:

• Try阶段：
  完成所有业务检查（一致性），预留业务资源(准隔离性)

• Confirm阶段：
  确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源

• Cancel阶段：
  取消Try阶段预留的业务资源。

image.png image.png

• 从业务服务
  每个从业务服务需要提供try接口供主业务服务调用，需要提供confirm、cancel接口供事务管理器调用。
  confirm和cancel接口需要设计为幂等性，因为事务管理/协调器调用失败的时候会重试。
  try接口可以设计返回预留资源的expire（过期时间），如果过期时间到了，事务管理/协调器还没有调用confirm或cancel接口，从业务服务自动释放预留的资源。

• 事务管理/协调器
  事务管理/协调器需要提供的事务日志上报接口，让主业务服务上报try阶段各个从业务服务资源是否预留成功的信息；
  如果各个从业务服务资源都预留成功，调用各个从业务服务的confirm接口；
  如果有一个从业务服务资源都预留失败，调用各个从服务的cancel接口；
  如果调用从业务服务confirm或cancel接口失败，需要重试调用。

• 主业务服务：主业务服务不需要提供任何接口，只需要调用从业务服务、事务管理/协调器提供的接口即可。

TCC事务的优缺点：

• 优点
  XA两阶段提交资源层面的，而TCC实际上把资源层面二阶段提交上提到了业务层面来实现。有效了的避免了XA两阶段提交占用资源锁时间过长导致的性能地下问题。
  支持多个从业务服务与主业务服务的数据最终一致性。
• 缺点
  主业务服务和从业务服务都需要进行改造，从业务方改造成本更高，需要改造成try、confirm、canel 3个接口，开发成本高。

可靠消息最终一致性

消息发送一致性是指产生消息的业务动作与消息发送的一致。也就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去，否则就丢消息。
消息发送一致性有两种方案

• RocketMQ事务消息实现

  
  image.png

• 本地消息表实现
  由于产生消息的业务动作操作的表与消息表在同一个数据库，这样就由数据库事务来保证当业务动作执行成功，消息就一定能成功落库。

image.png