TCC分布式事务框架设计.pdfVIP

TCC 分布式事务框架设计 1 一个 TCC 事务框架需要解决的当然是分布式事务的管理。 TCC 事务模型虽然说起来简单，然 而要基于 TCC 实现一个通用的分布式事务框架，却比它看上去要复杂的多，不只是简单的调 用一下 Confirm/Cancel 业务就可以了的。 本文将以 Spring 容器为例，试图分析一下，实现一个通用的 TCC 分布式事务框架需要注意的 一些问题。 一、 TCC 全局事务必须基于 RM 本地事务来实现全局事务 TCC 服务是由 Try/Confirm/Cancel 业务构成的，其 Try/Confirm/Cancel 业务在执行时，会 访问资源管理器（ Resource Manager ，下文简称 RM ）来存取数据。这些存取操作，必须要 参与 RM 本地事务，以使其更改的数据要么全部 commit ，要么全部 rollback 。 这一点不难理解，考虑一下如下场景： 2 假设图中的服务 B 没有基于 RM 本地事务（以 RDBS 为例，可通过设置 auto-commit 为 true 来模拟），那么一旦 [B:Try] 操作中途执行出错， TCC 事务框架后续决定回滚全局事务时，该 [B:Cancel] 则需要判断 [B:Try] 中哪些操作已经写到 DB 、哪些操作还没有写到 DB ：如果 [B:Try] 业务有 5 个写库操作， [B:Cancel] 业务则需要逐个判断这 5 个操作是否生效，并将生效的操作 执行反向操作。 不幸的是，由于 [B:Cancel] 业务也有 n （0=n=5 ）个反向的写库操作，此时一旦 [B:Cancel] 也中途出错，则后续的 [B:Cancel] 执行任务更加繁重。因为，相比第一次 [B:Cancel] 操作，后 续的 [B:Cancel] 操作还需要判断先前的 [B:Cancel] 操作的 n （0=n=5 ）个写库中哪几个已经 执行、哪几个还没有执行，这就涉及到了幂等性问题。 然而，对幂等性的保障，很可能也需要涉及额外的写库操作，该写库操作又会因为没有 RM 本 地事务的支持而存在类似问题。。。 可想而知，如果不基于 RM 本地事务， TCC 事务框架是无法有效的管理 TCC 全局事务的。 反之， 基于 RM 本地事务的 TCC 事务， 这种情况则会很容易处理： [B:Try] 操作中途执行失败， TCC 事务框架将其参与 RM 本地事务直接 rollback 即可。后续 TCC 事务框架决定回滚全局事 务时，在知道“ [B:Try] 操作涉及的 RM 本地事务已经 rollback ”的情况下，根本无需执行 [B:Cancel] 操作。 3 换句话说，基于 RM 本地事务实现 TCC 事务框架时，一个 TCC 型服务的 Cancel 业务要么执 行，要么不执行，不需要考虑部分执行的情况。 二、 TCC 事务框架应该接管 Spring 容器的 TransactionManager 基于 RM 本地事务的 TCC 事务框架，可以将各 Try/Confirm/Cancel 业务看着一个原子服务： 一个 RM 本地事务提交，参与该 RM 本地事务的所有 Try/Confirm/Cancel 业务操作都生效；