最终成功

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

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

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

最终成功的情况

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

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

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

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

消息的分支操作是最终成功的，因为消息不支持回滚。如果您需要回滚，那么请采用其他事务模式
SAGA事务如果有些正向操作是无法回滚的，那么您可以用普通非并发的SAGA，将可回滚的分支Ri放在前面，不可回滚的分支Ni放在后面。如果分支Ri正向操作失败，则会回滚Ri，一旦到了Ni，保证Ni的正向操作最终成功，这样也能够保证SAGA事务的正确运行
TCC事务的Confirm/Cancel是最终成功的，一般的设计是在TCC的Try阶段预留资源，检查约束条件，然后在Confirm阶段修改数据，在Cancel阶段释放预留的资源。经过精心的设计，能够在业务逻辑上保证Confirm/Cancel的最终成功

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