分布式事务解决方案Seata入门介绍

前言

在介绍Seata之前先来聊聊分布式事务的问题！在现在大型互联网项目中，不可能只有一台服务器，而是多台服务器，那么微服务又提倡独立数据库的概念，就是每个微服务分而治之的意思，那么大型互联网项目中就是一个项目对应许多微服务，然后微服务又有可能搭配多个数据库，那么就形成了多对多 ，如电商项目，订单微服务对应订单数据库，库存服务对应库存数据库，支付服务对应支付数据库，甚至部署在不同的机房，那么这时候就多数据源多中心的跨库的调用，那么业务顺序是下单成功新增一条订单记录，库存扣掉一条库存，库存扣完后再扣除支付金额，那么这三个操作连三个不同的库，那么说白了这三个数据库相当于一个整体，物理上他们可能是三个不同的数据库，但是逻辑上是同一个事务，牵扯到全局的跨数据库多数据源统一调度的这就是分布式事务的前身和雏形，那么事务发展的历程也就是1:1=>1:N=>N:N。

痛点

单体应用被拆分成微服务应用，原来的三个模块被三个独立的应用，分别使用三个独立数据源，业务操作需要调用三个服务来完成。此时每个服务内部的数据一致性由本地事务来保证，但是全局的数据一致性问题没法保证。

还是那前言部分的例子来说！用户购买商品的业务逻辑。整个业务逻辑由3个微服务提供支持

• 仓储服务：对给定的商品扣除仓储数量
• 订单服务：根据采购需求创建订单
• 账户服务：从用户账户中扣除余额
  
  如果数据一致性无法保证的情况下，那么我们的微服务架构是失败的
  重点：一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式事务问题
  Seata也就是解决全局数据一致性没法保证的问题

Seata简介

官网

Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
点击快速入门

Seata的官网感觉比Nacos写的要好一些

分布式事务处理过程的-ID+三组件模型

三个组件
Transaction Coordinator(TC) ：事务协调者，事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚;
Transaction Manager（TM)：事务管理器，控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议;
Resource Manager(RM)：资源管理器，控制分支事务，负责分支注册，状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚；

一个ID
Transaction ID XID：全局唯一的事务ID，还是那前言部分的例子来讲，涉及到三个数据库，也就是三个数据源，那么逻辑上属于同一事务的那么就要使用同一个事务ID

事务模式

以下摘自seata官方文档

tx1 二阶段全局提交，释放 全局锁 。tx2 拿到 全局锁 提交本地事务。，这里尝试获取全局锁默认为10次


这里光看官网可能不是很好理解，搞清楚两把锁，和两个阶段，就好理解了，本地锁（一条记录的行锁这样的概念），全局锁（TC服务器颁发的全局锁，类似于分布式锁这样的概念），本地锁和全局锁都是只有一个！。在多个业务请求进来时，如tx1、tx2、或者还有txxxx等，会先争抢本地锁，抢到本地锁后修改数据，在要提交的时候会去获取全局锁，没有抢到本地锁的请求业务那么就会等待抢到本地锁并且获取到全局锁的业务提交完成释放本地锁了才能进行业务，那么这些就是阶段一的操作，那么阶段二就是全局事务的提交和回滚问题，这里分为两种情况，情况一：业务正常就会提交全局事务，这个好理解。情况二：业务出现异常，需要回滚，那么例如先执行的业务为tx1，当tx1执行到阶段1获取全局锁提交本地事务后，然后业务异常需要回滚准备进入阶段二时，由于tx1在阶段一时获取到全局锁后，本地事务已经提交，并且释放了本地锁，那么等待的其他业务如tx2这是就能获取到本地锁，并且开始执行阶段一，但是由于这个时候全局锁还在tx1业务上，而本地锁在tx2业务上，并且tx1在阶段二需要回滚的时候需要本地锁，tx2在阶段一提交的时候需要全局锁，那么这个时候就都会等待，但是出于阶段一的tx2等待全局锁的，是等不过处于阶段二tx1等待本地锁的，那么此时处于阶段一的tx1就会抛出io.seata.rm.datasource.exec.LockWaitTimeoutException: Global lock wait timeout这个异常！从而释放掉本地锁，那么处于阶段二的tx2那么就会获得全局锁从而实现业务数据的回滚，从而也保障了不会发生脏写的问题，这里插一句两个事务操作不同的数据库或者表，全局锁是同一个！

AT模式基本上能满足我们使用分布式大部分需求，但涉及非关系行数据库于中间件的操作，夸公司服务的调用，跨语言的应用调用需要结合TCC模式！

AT是Seata基于undo_log表来帮我们实现回滚，而TCC则需要我们自己手动实现，不用基于undo_log表实现！