分布式事务的集中模式

在项目里面实现分布式事务，我们常用的一般有集中模式，分别是：AT模式，TCC模式，Saga模式。下面分别介绍下对应的业务场景。

一、AT模式

AT模式其实就是一个二阶段提交的模型，使用AT模式的时候，分布式数据库中，我们一般会配备一张undo_log的表，这样事务会在执行的时候，预先生成一个undo_log的信息，方便进行回滚。一般我在使用seata的时候，直接使用globalTransaction其实就是使用的T模式。

这里特别说明一下，传统的数据库的读隔离是读已提交，但是seata的隔离级别是读未提交，在seata中如果要求全部是读已提交，那么需要使用select for update的语句进行代理。

举个例子：如果我们要更新一个操作的时候： update product set productname = 'aaaa'  where productname = 'bbb',

那么在一阶段的时候，一般是执行 select id,productname,stock from product where productname = 'bbb'，例如查询后是：

查询完后，这边还会再执行一下:select id,productname,stock from product where id = 1; 通过这里的id进行定位数据，然后组成一条可以回滚的日志记录，插入到undo_log里面去。

{
 "branchId": 641789253,
 "undoItems": [{
  "afterImage": {
   "rows": [{
    "fields": [{
     "name": "id",
     "type": 1,
     "value": 1
    }, {
     "name": "productname",
     "type": 12,
     "value": "aaaa"
    }, {
     "name": "stock",
     "type": 12,
     "value": "1"
    }]
   }],
   "tableName": "product"
  },
  "beforeImage": {
   "rows": [{
    "fields": [{
     "name": "id",
     "type": 4,
     "value": 1
    }, {
     "name": "productname",
     "type": 12,
     "value": "bbb"
    }, {
     "name": "stock",
     "type": 12,
     "value": "1"
    }]
   }],
   "tableName": "product"
  },
  "sqlType": "UPDATE"
 }],
 "xid": "xid:xxx"
}

组成这样的json，方便进行回滚。在二阶段如果不成功的话，就直接执行回滚的信息

二、TCC模式

tcc模式就是自己定义try-confirm-cancel阶段的代码，这里在更新的时候，需要使用dto，这样子数据进行更齐全一点。不再多说。

三、saga模式

saga模式主要解决的是长事务的业务场景。他是描述的一整个业务场景流程中，在整个流程中，每一个参与者都提交自己的本地事务，当出现某一个参与者失败了，则补偿前面已经成功的参与者。所以需要开发一阶段的正向业务，还要开发二阶段的补偿业务。适用于业务流程长，业务流程多的场景里面。