阿里P8：图解微服务下的分布式事务以及解决方案（微服务阿里巴巴）

新鲜事 admin 2023-04-12 15:12 76 0

原标题：阿里P8：图解微服务下的分布式事务以及解决方案

最近有一个读者在我的一篇文章下方给我评论了上面的截图中的这样的一条信息，而底下又有读者回复说：”这个可以涉及到分布式事务了“所以，周末闲来无聊就写下了这篇文章——分布式事务解决方案，希望对大家有所帮助。

我们在说到事务的时候，总会以转账作为经典案例：用户下单买东西，一次买卖过程会扣件库存，生成订单，扣减账户余额；在这样的情况下，如果要保证数据业务的成功，必须引入事务不再赘述在事务案例里面，我们的项目结构是这样的，Storage、Order、Account是一个服务里的三个功能模块，他们共同面对一个DB，这时候，启用本地事务，就可以实现三个操作的共同成功和共同失败。

本地事务然而，我们知道，如果库存、订单、账户分别在不同的服务当中，每个服务对应自己的DB，那么本地事务就没有办法去限制和判断其他操作是否一致性完成。这就需要引入分布式事务。

分布式事务分布式系统的三大原则：CAP我们介绍解决方案之前，我们先介绍分布式系统的三大原则，也就是总会被提到的CAP定理：一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)，分别解释一下：一致性：我们希望分布式系统中各个节点的数据能保证一致，这里的“一致”，对于主从数据库来说是指主库和从库要保证数据一致。

还是还有一层意思，就是分布式系统任何时刻数据都是最新状态比如我买了东西，接下来order和account返回的就是最新的状态，我能从数据库中直接查到；再比如我们刚对数据库insert了一条数据，立马select，我们希望从数据库中返回的就是刚刚insert的数据。

如果我们要做到以上所说的，我们需要master向slave同步数据后，slave同步数据并锁表（假设因为网络原因同步需要一些时间），不对外开放读的状态，直到slave数据修改成功后，解锁可用性：与一致性不同，所谓可用，就是每次访问数据时都能够得到数据，不能返回错误和超时，这一点看起来就和保证一致性的时候同步有些冲突，因为我们为了一致性得锁表，可能就会导致延时。

分区容错：分区容错是我们使用分布式，特别是主从复制时候的意义所在，它指的是其中一个结点挂了，不能使整个数据库集群收到影响，其他服务还是可以正常运行看了以上三个原则的特点，我们可以了解到，CAP不能够共存，如果需要每次返回都是最新数据，那么就可能存在系统延时，但是这又违反了可用性。

但无论如何，分区容错是必须保证的，集群不能因为某一个结点的宕机而整个垮掉那么所有的分布式解决方案，也就是基于满足AP或者CP来展开设计的还是基于上面的案例，我们来设计一个分布式事务解决方案：拿Storage和Order举例，既然业务上分成了两个服务，如果他们在各自的服务里面执行数据操作后，告诉某一个中心操作结果，如果各自的事务提交都成功，则整体成功，如果其中有一个事务失败，则一起回滚，这样一来不就可以控制分布式事务了吗。

分布式事务管理从上图我们可以看到，全局的事务可以通过一个专门的服务——Transaction Manager（TM）进行管理，它会去统计所有相关子事务的执行情况，如果全部提交成功，对应的全局事务正常结束就可以了（因为各个子事务已经完成了提交任务），如果其中有一个事务出现了问题，我们可以根据每个子事务上的undo log进行回滚，数据状态修复。

这其实就是Seata的实现原理：在一次分布式事务中，发起全局事务的服务会向Seata服务注册一个全局事务，这个全局事务会给各个子事务进行关联：