开发者说 | 分布式事务中间件 Seata 的设计原理( 四 )_：开发者说|分布式事务中间件Seata的设

简要说说整个全局事务的执行步骤：

TM 向 TC 申请开启一个全局事务，TC 创建全局事务后返回全局唯一的 XID，XID 会在全局事务的上下文中传播；RM 向 TC 注册分支事务，该分支事务归属于拥有相同 XID 的全局事务；TM 向 TC 发起全局提交或回滚；TC 调度 XID 下的分支事务完成提交或者回滚。与 XA 方案有什么不同？

Seata 的事务提交方式跟 XA 协议的两段式提交在总体上来说基本是一致的，那它们之间有什么不同呢？

我们都知道 XA 协议它依赖的是数据库层面来保障事务的一致性，也即是说 XA 的各个分支事务是在数据库层面上驱动的，由于 XA 的各个分支事务需要有 XA 的驱动程序，一方面会导致数据库与 XA 驱动耦合，另一方面它会导致各个分支的事务资源锁定周期长，这也是它没有在互联网公司流行的重要因素。

基于 XA 协议以上的问题，Seata 另辟蹊径，既然在依赖数据库层会导致这么多问题，那我就从应用层做手脚，这还得从 Seata 的 RM 模块说起，前面也说过 RM 的主要作用了，其实 RM 在内部做了对数据库操作的代理层，如下：