背景
既然要给大家讲什么是 seata，那就得先说一下这个东西的定位，这东西就是现在很火的 Spring Cloud Alibaba 里的一个组件，是专门帮助我们解决分布式事务问题的，也就是说，seata 是一个分布式事务框架。
什么是分布式事务
那可能很多小伙伴很蒙圈了，什么是分布式事务？好吧，为了保证大家能继续看下去，我们先说一下什么是分布式事务这个问题。
举个最简单的例子，假设现在你负责了一个订单系统，一个库存系统，一个营销系统，然后呢，当你的订单系统收到用户一个请求要创建订单的时候，这个时候你得做三件事情。
第一，调用库存系统的接口锁定库存，第二，调用调用营销系统的接口锁定优惠券，第三，你订单系统自己得在 MySQL 里插入一系列订单的数据。
比如下图 1 所示：
那么现在问题来了，你订单系统有自己的订单数据库，可以去插入订单数据，那库存系统是不是也应该有自己的库存数据库，去锁定库存数据？
营销系统是不是应该有自己的营销数据库，去锁定优惠券？当然是了！每个人都有自己的数据库，这一个都不能少。
如下图 2 所示：
?
那现在问题又来了，既然一次创建订单的请求，要涉及到订单、库存、营销三个系统，分别操作各自自己的三个数据库，才能完成这次请求。
那是不是可能会出现这么一种情况，首先呢，你先调用库存系统，锁定了库存了，O 了。
接着呢，你又调用了营销系统，锁定了优惠券，也 O 了。最后呢，当你订单系统要往自己的订单数据库里插入数据的时候，网络抽风了，导致你这一次插入订单数据失败了，直接 exception 异常了，你蒙圈了。
如下图 3 所示：
?
那这个时候你觉得可能会产生什么样的问题呢，其实很简单，这个时候你这个订单要购买的商品库存已经被锁定了，你为了下这个订单用的优惠券，也已经被锁定了。
结果呢，你的订单自己本身的数据并没进入数据库，然后还返回一个了异常信息给用户说，本次下单失败。
但是你说下单失败就失败吧，结果呢，运营看库存数据的时候可能会一脸蒙圈，为啥有一些商品库存被锁定了，结果没有对应的跟订单，而且一直没人付款来购买呢？？
然后用户自己也有点发蒙，因为一查自己的优惠券，好不容易攒了几张券来买东西，结果现在订单没下成，优惠券状态都搞成已使用了，自己还没法用这些优惠券了。
如下图 4 所示：
其实这就是一个非常经典的分布式事务的问题了，你一个创建订单的请求，横跨了订单、库存、营销三个系统，分别涉及三个数据库。
所有很可能会发现，你的库存和营销的数据操作都成功了，而且库存和营销数据库里的本地事务都提交了，结果订单插入数据库失败了，订单数据库里的本地事务回滚了，但是库存和营销数据库里的本地事务已经提交了，他们是不会回滚的。
如下图 5 所示：
什么叫做逆向补偿
那既然问题已经找到了，我们希望的应该是什么效果呢？
我们其实希望的效果是，如果订单要是插入数据库失败了，订单数据库本地事务回滚了，我们应该想办法去通知一下库存系统和营销系统，把之前在库存数据库和营销数据库里已经提交的数据修改做一个逆向补偿，进行恢复。
什么叫做逆向补偿呢？意思就是说，之前库存系统如果在数据库里执行的是 insert，那么此时就应该执行 delete，把之前插入的数据删除了。
如果之前执行的 delete，现在就应该执行 insert，把删除的额数据重新插入回去，如果之前执行的是 udpate 语句，现在就应该再次执行一个 update 语句，把数据恢复到更新之前的状态。
如下图 6 所示：
互联网最流行的分布式事务组件 seata
那既然我们想要实现这个效果，这个时候问题就来了，单单依赖我们自己那肯定搞不定这个问题了，这个时候就必须引入 Spring Cloud Alibaba 里的大佬组件，seata。
seata 就是专门帮助我们解决这个问题的，如果我们要是在系统里引入 seata 框架之后，其实每个系统里都会嵌入 seata，同时我们还需要去部署一个 seata server。
如下图 7 所示：
这个时候，我们的系统运行原理会变成这样：订单系统中的 seata 会发送请求给 seata server 去开启一个全局事务，然后库存系统先运行，他在进行数据库 crud 的时候，这些操作都会被 seata 框架进行拦截。
然后 seata 框架会在一个本地事务里，把你的 sql 语句和逆向补偿日志，一起插入到你的库存数据库里去，在库存数据库里必须有一个 undo_log 表，存储 seata 的逆向补偿日志。
那这个逆向补偿日志是什么呢？简单，如果你的 sql 是 insert，那逆向补偿日志可以帮助你后续构建 delete 语句来删除，如果你的 sql 是 update，那逆向补偿日志可以记录你更新之前的旧数据，他可以帮助你后续把数据 update 到老版本的状态。
如下图 8 所示：
你库存系统的 sql 语句和他们的补偿日志，是在一个本地事务里一起提交的，一起成功或者一起失败，所以但凡你的库存系统更新成功了，就一定会有对应的补偿日志也会在库存 数据库里的，以备不时之需，营销系统其实也是相同的运行原理。
那么假设说库存系统和营销系统，按照这个思路都执行完毕了，到订单系统了，他结果撂挑子了，插入订单数据库失败。
当然，在插入的时候其实也会有对应的补偿日志会一起提交，但是因为这个时候网络问题，导致插入订单和插入补偿日志一起失败了。
所以此时订单系统的 seata 就会上报 seata server 说，大哥，我这儿完犊子了，您要不通知库存和营销两个兄弟，逆向补偿一下吧。
如下图 9 所示：
接着 seata server 发现说，这分布式事务都失败了，那赶紧的，他会通知库存系统和营销系统里的 seata 框架小兄弟说，兄弟们，赶紧的，把之前插入你们数据库里的 undo_log 表里的补偿日志拿出来，构建一下逆向补偿 sql。
之前是 insert 你就给我弄个 delete，之前是 delete 你就给我弄个 insert，之前是 update 你还是 update，逆向补偿 sql 赶紧跑一把，把数据给我恢复了，前队改后队，跑步前进，hurry up 起来。
如下图 10 所示：
总结
太棒了，到这个时候为止，我们就发现 seata 老大的作用了，你订单、库存、营销三个系统随便跑，有谁失败了，seata server 收到你的失败通知，就会告诉别的系统用 undo log 日志构建补偿 sql，把数据都给回滚了，完美。
