二、Seata

二、Seata

    1、2019年，基于TXC（Taobao Transaction Constructor）和GTS（Global Transaction Service）的技术积累，阿里中间件团队发起了开源项目Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社区一起建设这个分布式事务解决方案。起初起名为Fescar，后更名为Seata。

        (1)、设计初衷

            ①、对业务无侵入

                这里的侵入是指，因为分布式事务这个技术问题的制约，要求应用在业务层面进行设计和改造。这种设计和改造往往会给应用带来很高的研发和维护成本。我们希望把分布式事务问题在中间件这个层次解决掉，不要求应用在业务层面做额外的工作。

            ②、高性能

                引入分布式事务的保障，必然会有额外的开销，引起性能的下降。我们希望把分布式事务引入的性能损耗降到非常低的水平，让应用不因为分布式事务的引入导致业务的可用性受影响。

        (2)、组件

            ①、Transaction Coordinator（TC）：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。

            ②、Transaction Manager（TM）：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。

            ③、Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

        (3)、流程

            ①、TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID。

            ②、XID在微服务调用链路的上下文中传播。

            ③、RM向TC注册分支事务，将其纳入XID对应全局事务的管辖。

            ④、TM向TC发起针对XID的全局提交或回滚决议。

            ⑤、TC调度XID下管辖的全部分支事务完成提交或回滚请求。

        (4)、Seata方案与XA方案比较

            ①、架构层次

                XA方案的RM实际上是在数据库层，RM本质上就是数据库自身（通过提供支持XA的驱动程序来供应用使用）。

                而Seata的RM是以Jar包的形式，作为中间件层部署在应用程序这一端的，不依赖与数据库本身对协议的支持，当然也不需要数据库支持XA协议。

                这点对于微服务化的架构来说是非常重要的：应用层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。

                这个设计，剥离了分布式事务方案对数据库在协议（XA协议）支持上的要求。

            ②、两阶段提交

                a、XA方案无论Phase2的决议是commit还是rollback，事务性资源的锁都要保持到Phase2完成才释放。

                设想一个正常运行的业务，大概率是90%以上的事务最终应该是成功提交的&