分布式事务框架-TCC

最新推荐文章于 2024-09-11 15:19:41 发布

奔啵儿鮁

最新推荐文章于 2024-09-11 15:19:41 发布

阅读量593

点赞数

文章标签：分布式

本文链接：https://blog.csdn.net/qq_44545083/article/details/104405458

版权

在这里插入图片描述
TCC事务框架应该具备故障恢复机制
一个TCC事务框架，若是没有故障恢复的保障，是不称其为分布式事务框架的。
分布式事务管理框架的职责，不是做出全局事务提交/回滚的指令，而是管理全局事务提交/回滚的过程。
它需要能够协调多个RM资源、多个节点的分支事务，保证它们按全局事务的完成方向各自完成自己的分支事务。
这一点，是不容易做到的。因为，实际应用中，会有各种故障出现，很多都会造成事务的中断，从而使得统一提交/回滚全局事务的目标不能达到，甚至出现”一部分分支事务已经提交，而另一部分分支事务则已回滚”的情况。
比较常见的故障，比如：业务系统服务器宕机、重启；数据库服务器宕机、重启；网络故障；断电等。这些故障可能单独发生，也可能会同时发生。
作为分布式事务框架，应该具备相应的故障恢复机制，无视这些故障的影响是不负责任的做法。
一个完整的分布式事务框架，应该保障即使在最严苛的条件下也能保证全局事务的一致性，而不是只能在最理想的环境下才能提供这种保障。退一步说，如果能有所谓“理想的环境”，那也无需使用分布式事务了。
TCC事务框架要支持故障恢复，就必须记录相应的事务日志。事务日志是故障恢复的基础和前提，它记录了事务的各项数据。
TCC事务框架做故障恢复时，可以根据事务日志的数据将中断的事务恢复至正确的状态，并在此基础上继续执行先前未完成的提交/回滚操作。
在这里插入图片描述

TCC事务框架应该提供Confirm/Cancel服务的幂等性保障

一般认为，服务的幂等性，是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求，二者具有相同的副作用。
在TCC事务模型中，Confirm/Cancel业务可能会被重复调用，其原因很多。
比如，全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时，可能会出现如网络中断的故障而使得全局事务不能完成。
因此，故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务，这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务逻辑。
既然Confirm/Cancel业务可能会被多次调用，就需要保障其幂等性。
那么，应该由TCC事务框架来提供幂等性保障？还是应该由业务系统自行来保障幂等性呢？

个人认为，应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个问题的话，那么由业务系统来负责也是可以的；
然而，这是一类公共问题，毫无疑问，所有TCC服务的Confirm/Cancel业务存在幂等性问题。TCC服务的公共问题应该由TCC事务框架来解决；
而且，考虑一下由业务系统来负责幂等性需要考虑的问题，就会发现，这无疑增大了业务系统的复杂度。

TCC事务框架不能盲目的依赖Cancel业务来回滚事务
前文已经提到过，TCC事务通过Cancel业务来对Try业务进行回撤的机制暗含了一个事实：Try操作已经生效。

也就是说，只有Try操作所参与的RM本地事务已经提交的情况下，才需要执行其Cancel操作进行回撤。没有执行、或者执行了但是其RM本地事务被rollback的Try业务，是一定不能执行其Cancel业务进行回撤的。

因此，TCC事务框架在全局事务回滚时，应该根据TCC服务的Try业务的执行情况选择合适的处理机制。而不能盲目的执行Cancel业务，否则就会导致数据不一致。
一个TCC服务的Try操作是否生效，这是TCC事务框架应该知道的，因为其Try业务所参与的RM事务也是由TCC事务框架所commit/rollbac的（前提是TCC事务框架接管了Spring的事务管理器）。
所以，TCC事务回滚时，TCC事务框架可考虑如下处理策略：