Seata：Hello World

一、目标

        Seata 是阿里巴巴开源的一款分布式事务中间件，它的愿景是让分布式事务的使用像本地事务的使用一样，以高效并且对业务0侵入的方式，解决微服务场景下面临的分布式事务问题。

二、原理和设计

        要设计一个对业务无侵入的方案，所以从业务无侵入的 XA 方案来思考：是否可以在 XA 的基础上演进，解决掉 XA 方案面临的问题呢？

1、如何定义一个分布式事务？

        很自然的，我们可以把一个分布式事务理解成一个包含了若干分支事务的全局事务。

        全局事务的职责就是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个满足 ACID 的本地事务。通过对分布式事务结构的基本认识，这与 XA 是一致的。

2、怎么发起全局事务，协调分支事务达成一致？

        这与 XA 的模型类似，我们定义3个组件来协议分布式事务的处理过程。

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

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

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

        一个典型的分布式事务过程：

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

        2. XID 在微服务调用链路的上下文传播。

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

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

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

        从上面过程看起来，Seata 的协议机制总体上与 XA 是一致的。

三、适用场景

        Seata 的核心原理中有一个重要前提：分支事务中涉及的资源，必须是支持 ACID 事务的关系型数据库。

        分支的提交和回滚机制，都依赖于本地事务的保障。所以，如果应用使用的数据库不支持事务的，或根本不是关系型数据库，就不适用。

---

引用

官方文档