最终成功

dtm里多种事务模式中,都出现了操作最终成功的要求,这是什么含义呢?哪些场景是最终成功的?为什么要求最终成功?应用怎么设计?

最终成功并不是说要保证100%的成功,它允许暂时性失败:包括网络故障,系统宕机,系统bug;但是一旦暂时性的问题解决之后,在业务恢复之后,需要返回成功。

最终成功的另一个说法是,该操作能够最终成功,即通过不断重试,最后会返回成功。

最终成功的情况

最终成功的情况包括以下方面

  • 二阶段消息中的分支操作
  • SAGA中的补偿操作
  • TCC的Confirm和Cancel操作

您的业务需要保证以上的操作,在业务逻辑上是可以最终成功的。

为什么要最终成功

假如您的业务使用了SAGA,然后依次出现下面情况:

  • 某个操作出现失败需要回滚
  • 回滚的过程中,遇见回滚失败
  • 此时SAGA事务既无法往前执行,也无法往后回滚

这是由于您的业务系统逻辑设计中的问题,分布式事务没有任何办法解决,所以您的业务需要保证回滚是可以最终成功的。

应用如何设计

  • 二阶段消息的分支操作是最终成功的,因为二阶段消息不支持回滚。如果您需要回滚,那么请采用其他事务模式

  • SAGA事务如果有些正向操作是无法回滚的,那么您可以用普通非并发的SAGA,将可回滚的分支Ri放在前面,不可回滚的分支Ni放在后面。如果分支Ri正向操作失败,则会回滚Ri,一旦到了Ni,保证Ni的正向操作最终成功,这样也能够保证SAGA事务的正确运行

  • TCC事务的Confirm/Cancel是最终成功的,一般的设计是在TCC的Try阶段预留资源,检查约束条件,然后在Confirm阶段修改数据,在Cancel阶段释放预留的资源。经过精心的设计,能够在业务逻辑上保证Confirm/Cancel的最终成功

注意点

在实际的业务应用中,可能会出现某些应用bug,导致要求最终成功的操作,一直无法成功,导致数据一直无法达到最终一致。建议开发者对全局事务表进行监控,发现重试超过3次的事务,发出报警,由运维人员找开发手动处理,参见dtm的运维