干货！如何设计实现一个通用的分布式事务框架？.docxVIP

干货！如何设计实现一个通用的分布式事务框架？ 2021-04-19 一个TCC事务框架需要处理的当然是分布式事务的管理。关于TCC事务机制的引见，可以参考TCC事务机制简介。 TCC事务模型虽然说起来简约，然而要基于TCC实现一个通用的分布式事务框架，却比它看上去要简单的多，不只是简约的调用一下Confirm/Cancel业务就可以了的。 本文将以Spring容器为例，试图分析一下，实现一个通用的TCC分布式事务框架需要留意的一些问题。 一、TCC全局事务必需基于RM本地事务来实现 TCC服务是由Try/Confirm/Cancel业务构成的，其Try/Confirm/Cancel业务在执行时，会访问资源管理器（Resource Manager，下文简称RM）来存取数据。 这些存取操作，必需要参与RM本地事务，以使其更改的数据要么都commit，要么都rollback。 这一点不难理解，考虑一下如下场景： 假设图中的服务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]操作。 换句话说，基于RM本地事务实现TCC事务框架时，一个TCC型服务的cancel业务要么执行，要么不执行，不需要考虑部分执行的情况。 二、TCC事务框架应当接管Spring容器的TransactionManager 基于RM本地事务的TCC事务框架，可以将各Try/Confirm/Cancel业务看成一个原子服务：一个RM本地事务提交，参与该RM本地事务的全部Try/Confirm/Cancel业务操作都生效；反之，则都不生效。 把握每个RM本地事务的形态以及它们与Try/Confirm/Cancel业务方法之间的对应关系，以此为基础，TCC事务框架才能有效的构建TCC全局事务。 TCC服务的Try/Confirm/Cancel业务方法在RM上的数据存取操作，其RM本地事务是由Spring容器的PlatformTransactionManager来commit/rollback的，TCC事务框架想要了解RM本地事务的形态，只能通过接管Spring的事务管理器功能。 2.1. 为什么TCC事务框架需要把握RM本地事务的形态？首先，依据TCC机制的定义，TCC事务是通过执行Cancel业务来达到回滚效果的。认真分析一下，这里暗含一个现实：只要生效的Try业务操作才需要执行对应的Cancel业务操作。 换句话说，只要Try业务操作所参与的RM本地事务被commit了，后续TCC全局事务回滚时才需要执行其对应的Cancel业务操作 否则，假如Try业务操作所参与的RM本地事务被rollback了，后续TCC全局事务回滚时就不能执行其Cancel业务，此时若盲目执行Cancel业务反而会导致数据不全都。 其次，Confirm/Cancel业务操作必需保证生效。Confirm/Cancel业务操作也会涉及RM数据存取操作，其参与的RM本地事务也必需被commit。 TCC事务框架需要在精确?????的晓得全部Confirm/Cancel业务操作参与的RM本地事务都被成功commit后，才能将标记该TCC全局事务为完成。 假如TCC事务框架误判了Confirm/Cancel业务参与RM本地事务的形态，就会形成全局事务不全都。 最终，未完成的TCC全局，TCC事务框架必需重新