Alibaba Seata 实现分布式事务（一） 2022-03-30 程序之旅,记录 1 条评论 3828 次阅读 ## Alibaba Seata 实现分布式事务（一） > 分布式事务是指一次大的操作分为不同的小操作，而这些小操作分布在不同的微服务中，分布式事务需要保证这些小操作要么完全地执行，要么完成地不执行。 分布式事务的产生原因 - 业务的微服务化 - 数据库分库分表 ### 分布式事务的解决方案 分布式框架中的两种经典的解决方案：二阶段提交 2PC 和 三阶段提交 3PC。 #### 二阶段提交（2PC：Two-Phase Commit） 该协议将一个分布式的事务过程拆分成两个阶段：事务预处理阶段和提交阶段。相对于单事务来说，分布式事务增加了 `事务协调者` 这个角色，用于协调整个数据库集群节点的开启、提交与回滚的处理。微服务是执行业务事件的角色。 ##### 提交过程 阶段一：事务预处理阶段 该步骤主要目的在于打探数据库集群中的各个参与者是否能够正常的执行事务，具体步骤如下： - `事务协调者`向所有参与者发送事务执行请求，并等待微服务反馈事务执行结果； - 微服务收到请求后，执行业务操作，但不提交事务，记录事务日志； - 微服务将自己事务执行情况反馈给`事务协调者`，同时阻塞等待`事务协调者`的后续指令。 阶段二：提交阶段 根据微服务回复的执行情况来看，可以分为三种情况： 1、所有的微服务都回复正常执行事务； 2、一个或多个微服务事务执行失败； 3、`事务协调者`等待超时。 对于第一种情况，`事务协调者`具体的步骤如下： 1、`事务协调者`向各个微服务发送 commit 通知，请求提交事务； 2、微服务提交事务，释放资源； 3、微服务向`事务协调者`返回 commit 结果信息。 对于第二、三情况，`事务协调者`均认为微服务无法成功完成事务，为了保证集群数据的一致性，向各个微服务发送回滚通知，具体步骤如下： 1、`事务协调者`向各个微服务发送 rollback通知，请求回滚事务； 2、微服务回滚事务，释放资源； 3、微服务向`事务协调者`返回 rollback 结果信息。 ##### 出现的问题 无论阶段一的情况如何，阶段二都会接受当前事务，对于`二阶段提交(2PC)`来说，存在以下问题： 1、**同步阻塞问题**：执行过程中，所有参与节点都是事务阻塞，当微服务因为网络原因无法收到`事务协调者`下达的提交命令，则未提交的数据就会被长时间阻塞，可能导致系统崩溃。 2、**数据不一致问题：**基于第一个问题，如果微服务长时间阻塞，占用资源无法释放，过了一段时间后，微服务会因超时执行提交操作，释放被阻塞的资源，这样就会导致数据不一致的问题。或者是`事务协调者`发送 commit 或 rollback 命令时因为网络的原因也会导致部分微服务不能接收到命令，导致自动提交，释放资源，造成数据不一致。 3、**单点故障问题：**简单的说就是单机`事务协调者`宕机，微服务集群发生阻塞的问题。 #### 三阶段提交 为了解决二阶段提交的问题，三阶段提交引用的超时机制，保证数据库资源不会被长时间锁定。三阶段提交（3PC）把二阶段提交 (2PC) 分为三部分：事务预处理阶段(CanCommit) -> 预提交阶段(PreCommit) -> 提交阶段(DCommit) 阶段一：事务预处理阶段 3PC 第一阶段与 2PC 第一阶段的提交是一样的，`事务协调者`向微服务发送 commit 命令。 阶段二：预提交阶段 预提交阶段知识一个询问机制，以确认所有微服务都已准备好，同时对微服务设置了超时时间，防止资源的占用。当阶段二所有服务返回`可以提交`，进入阶段三`提交阶段`。 阶段三：提交阶段 如果协调者与服务通信中断导致无法提交，在服务端超时后也会自动执行提交操作来保证资源释放。 ### Alibaba Seata 分布式事务中间件 todo 介绍 alibaba seata Seata 全称 Simple Extensible Autonomous Transaction Architecture，是一套分布式事务解决方案。Seata 是基于 传统的 2PC 的基础上演进，做到业务无侵入性，把一个分布式事务事务理解成一个包含了若干分支事务的全局事务。 官网地址：http://seata.io  #### 特色特点  Seata 提供了多种分布式事务的解决方案，包括 AT 模式、TCC 模式、SAGA 模式以及 XA 模式。其中 AT 模式提供了最简单易用且无侵入的事务处理机制，通过自动生成方向 SQL 实现事务回滚。 ### 分析 Seata 的 AT 模式实现原理 seata 主要由三个重要的组件： - 事务协调者（TC）：管理全局的分支事务的状态，用于全局性事务的提交和回滚。 - 事务管理器（TM）：开启、提交或回滚全局事务。 - 资源管理器（RM）：用于分支事务上的资源管理，向 TC 注册分支事务，上报分支事务的状态，接收 TC 的命令来提交或回滚分支事务。  Seata 中 AT 的执行流程： > 假设有 A 和 B 两个服务组成全局事务 1. A 服务的 TM 向 TC 申请开启一个全局事务，TC 就会创建一个全局事务并返回一个唯一的 XID 2. A 服务的 RM 向 TC 注册分支事务，并及其纳入 XID 对应全局事务的管辖 3. A 服务执行分支事务，向数据库做操作 4. A 服务开始远程调用 B 服务，此时 XID 会在微服务的调用链上传播 5. B 服务的 RM 向 TC 注册分支事务，并将其纳入 XID 对应的全局事务的管辖 6. B 服务执行分支事务，向数据库做操作 7. 全局事务调用链处理完毕，TM 根据有无异常向 TC 发起全局事务的提交或者回滚 8. TC 协调其管辖之下的所有分支事务， 决定是否回滚 通过执行的流程可以看出，Seata 的 AT 模式并不是使用数据库的排它锁，而是实现先提交后回滚的机制保障一致性，这样的优点是能够避免资源的占用，进而导致服务崩溃的风向，但是这样会存在弊端，先提交后回滚是`读未提交`的隔离级别，在高并发的环境下容易产生脏读、幻读的情况。 ### FAQ 为什么 Seata 要生成反向 SQL，而不是利用数据库自带的排它锁机制处理？ 答：如果采用排它锁机制会导致数据资源被锁死，可能会产生大量的数据资源阻塞，进而存在应用崩溃的风险。 打赏: 微信, 支付宝 标签: 分布式, 微服务, spring cloud alibaba, seata 本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。
微信
支付宝
恭贺大佬喜提新域名