29. 聊聊最大努力通知方案？

解释一
最大努力送达，是针对于弱 XA 的一种补偿策略。它采用事务表记录所有的事务操作 SQL 。

img

  • 如果子事务提交成功，将会删除事务日志。
  • 如果执行失败，则会按照配置的重试次数，尝试再次提交，即最大努力的进行提交，尽量保证数据的一致性，这里可以根据不同的业务场景，平衡 C 和 A ，采用同步重试或异步重试。

? 优点

  • 无锁定资源时间，性能损耗小。

? 缺点

  • 尝试多次提交失败后，无法回滚，它仅适用于事务最终一定能够成功的业务场景。

? 总结

  • 因此 BED 是通过事务回滚功能上的妥协，来换取性能的提升。

貌似，暂时也想象不到具体的使用场景。

? 解决方案

正如上图，提供的解决方式 Sharding-JDBC ，具体的源码解析，可见 《Sharding-JDBC 源码分析 —— 分布式事务（一）之最大努力型》 。
解释二
这个方案的大致意思就是：

  1. 系统 A 本地事务执行完之后，发送个消息到 MQ；
  2. 这里会有个专门消费 MQ 的最大努力通知服务，这个服务会消费 MQ 然后写入数据库中记录下来，或者是放入个内存队列也可以，接着调用系统 B 的接口；
  3. 要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B，反复 N 次，最后还是不行就放弃。

? 解决方案

按照这个解释，RocketMQ 的消息重试，符合这个解释。具体的源码解析，见 《RocketMQ 源码分析 —— 定时消息与消息重试》 。

比较常见的场景，就是支付成功后，多次回调~