SpringCloud 分布式事务组件之Seata

目录

• 背景介绍
• 什么是分布式事务
• 什么叫做逆向补偿呢
• 互联网最流行的分布式事务组件seata
• 总结

背景

大家好，今天给大家分享一个在2022年出去面试Java几乎必问的一个技术，那就是seata。什么？？你才看了第一句话心里有闪现了无数个问号？因为没听说过seata这个东西？没关系，为了避免兄弟们出去面试被问到seata的时候，一脸蒙圈，我们今天就把这个东西给大家讲明白。

既然要给大家讲什么是seata，那就得先说一下这个东西的定位，这东西就是现在很火的 spring cloud alibaba里的一个组件，是专门帮助我们解决分布式事务问题的，也就是说，seata是一个分布式事务框架。

什么是分布式事务？

那可能很多小伙伴很蒙圈了，什么是分布式事务？ 好吧，为了保证大家能继续看下去，我们先说一下什么是分布式事务这个问题。

举个最简单的例子，假设现在你负责了一个订单系统，一个库存系统，一个营销系统，然后呢，当你的订单系统收到用户一个请求要创建订单的时候，这个时候你得做三件事情，第一，调用库存系统的接口锁定库存，第二，调用营销系统的接口锁定优惠券，第三，你订单系统自己得在MySQL里插入一系列订单的数据，比如下图1所示：

图1

那么现在问题来了，你订单系统有自己的订单数据库，可以去插入订单数据，那库存系统是不是也应该有自己的库存数据库，去锁定库存数据？营销系统是不是应该有自己的营销数据库，去锁定优惠券？当然是了！每个人都有自己的数据库，这一个都不能少，如下图2所示：

图2

那现在问题又来了，既然一次创建订单的请求，要涉及到订单、库存、营销三个系统，分别操作各自自己的三个数据库，才能完成这次请求。

那是不是可能会出现这么一种情况，首先呢，你先调用库存系统，锁定了库存了，O了。接着呢，你又调用了营销系统，锁定了优惠券，也O了。最后呢，当你订单系统要往自己的订单数据库里插入数据的时候，网络抽风了，导致你这一次插入订单数据失败了，直接exception异常了，你蒙圈了，如下图3所示：

图3

那这个时候你觉得可能会产生什么样的问题呢，其实很简单，这个时候你这个订单要购买的商品库存已经被锁定了，你为了下这个订单用的优惠券，也已经被锁定了，结果呢，你的订单自己本身的数据并没进入数据库，然后还返回一个了异常信息给用户说，本次下单失败。 但是你说下单失败就失败吧，结果呢，运营看库存数据的时候可能会一脸蒙圈，为啥有一些商品库存被锁定了，结果没有对应的跟订单，而且一直没人付款来购买呢？？然后用户自己也有点发蒙，因为一查自己的优惠券，好不容易攒了几张券来买东西，结果现在订单没下成，优惠券状态都搞成已使用了，自己还没法用这些优惠券了，如下图4所示：

图4

其实这就是一个非常经典的分布式事务的问题了，你一个创建订单的请求，横跨了订单、库存、营销三个系统，分别涉及三个数据库，所有很可能会发现，你的库存和营销的数据操作都成功了，而且库存和营销数据库里的本地事务都提交了，结果订单插入数据库失败了，订单数据库里的本地事务回滚了，但是库存和营销数据库里的本地事务已经提交了，他们是不会回滚的，如下图5所示：

图5

什么叫做逆向补偿呢？

那既然问题已经找到了，我们希望的应该是什么效果呢？我们其实希望的效果是，如果订单要是插入数据库失败了，订单数据库本地事务回滚了，我们应该想办法去通知一下库存系统和营销系统，把之前在库存数据库和营销数据库里已经提交的数据修改做一个逆向补偿，进行恢复。

什么叫做逆向补偿呢？ 意思就是说，之前库存系统如果在数据库里执行的是insert，那么此时就应该执行delete，把之前插入的数据删除了，如果之前执行的delete，现在就应该执行insert，把删除的额数据重新插入回去，如果之前执行的是udpate语句，现在就应该再次执行一个update语句，把数据恢复到更新之前的状态，如下图6所示：

图6

互联网最流行的分布式事务组件seata

那既然我们想要实现这个效果，这个时候问题就来了，单单依赖我们自己那肯定搞不定这个问题了，这个时候就必须引入spring cloud alibaba里的大佬组件，seata。seata就是专门帮助我们解决这个问题的，如果我们要是在系统里引入seata框架之后，其实每个系统里都会嵌入seata，同时我们还需要去部署一个seata server，如下图7所示：

图7

这个时候，我们的系统运行原理会变成这样，订单系统中的seata会发送请求给seata server去开启一个全局事务，然后库存系统先运行，他在进行数据库crud的时候，这些操作都会被seata框架进行拦截，然后seata框架会在一个本地事务里，把你的sql语句和逆向补偿日志，一起插入到你的库存数据库里去，在库存数据库里必须有一个undo_log表，存储seata的逆向补偿日志。

那这个逆向补偿日志是什么呢？简单，如果你的sql是insert，那逆向补偿日志可以帮助你后续构建delete语句来删除，如果你的sql是update，那逆向补偿日志可以记录你更新之前的旧数据，他可以帮助你后续把数据update到老版本的状态，如下图8所示：

图8

你库存系统的sql语句和他们的补偿日志，是在一个本地事务里一起提交的，一起成功或者一起失败，所以但凡你的库存系统更新成功了，就一定会有对应的补偿日志也会在库存数据库里的，以备不时之需，营销系统其实也是相同的运行原理。

那么假设说库存系统和营销系统，按照这个思路都执行完毕了，到订单系统了，他结果撂挑子了，插入订单数据库失败，当然，在插入的时候其实也会有对应的补偿日志会一起提交，但是因为这个时候网络问题，导致插入订单和插入补偿日志一起失败了，所以此时订单系统的seata就会上报seata server说，大哥，我这儿完犊子了，您要不通知库存和营销两个兄弟，逆向补偿一下吧，如下图9所示：

图9

接着seata server发现说，这分布式事务都失败了，那赶紧的，他会通知库存系统和营销系统里的seata框架小兄弟说，兄弟们，赶紧的，把之前插入你们数据库里的undo_log表里的补偿日志拿出来，构建一下逆向补偿sql，之前是insert你就给我弄个delete，之前是delete你就给我弄个insert，之前是update你还是update，逆向补偿sql赶紧跑一把，把数据给我恢复了，前队改后队，跑步前进，hurry up起来，如下图10所示：

图10

总结