138_分布式事务问题由来

好，各位同学大家好，那这一讲我们终于可以说进入到了我们spring cloud第二季的尾声哈，那么同学们也不容易跟着杨哥从第一章直接呢杀到了我们的第20章，那接下来，呃，理论上而言可以是说进入到了我们本门课程的最后一章第20章cloud，阿里巴巴的西塔处理分布式事务，嗯，经过这么八九天的学习哈，那么同学们呢，非常的疲惫，也非常的辛苦，同学们呢？就杨哥在这儿表示一下再次的歉意啊，没办法，疫情的影响必须要逼着大家有真本事真能耐。我还是那句话，硅谷学子不弱于人，前提是你正儿八经要。有干货，有知识有技能，好同学们，那么网络上人上线的也差不多满了，咱们呢，开工。下面来看一下西塔处理分布式事物。首先，事物。

兄弟们在学MYSQL的时候都玩过，那么上硅谷的MYSQL，换句话说，上上硅谷的数据库的课程呢，是分三部分组成，第一个比方说由这个柴老师、刘伟老师等等给大家讲的是MYSQL基础。高级部分由夏磊老师啊，或者后面的老师呢，给大家讲的是MYSQL高级，那么到我。炸。需要给大家说的是分布式啊，那么什么是分布式事务，我们怎么怎么的一点点的从初级到中级到高级呢？比如说啊，你现在呢，跟人家讲面试的时候，人家会问说你做过的项目用的技术架构什么呀，基于分布式的微服架构，100%会问你，那你们的分布式事务怎么控制的，因为只要说到。分布式，不可能你的数据库有且仅有一个，这就搞笑了。那么所以说我们要看看多数据库，多数据源的情况下，我们是如何处理和面对的来。

同学们先来说说分布式事物的问题好。首先啊，什么是分布式，什么是事物，到杨哥这儿，我认为大家是已经懂了，我就不再啰嗦和赘述，这个事儿我闭嘴，那么接下来我们呢，来看看。首先分布式之前单机单库没有这个问题。O吧，同学们在入学上硅谷的头两个月啊，学的是什么JSP啊，So time k gd bc my基础的时候，那说白了就是一个笔记本。又一个工程里面又装数据库又装Java，不多废话，那么现在怎么会干到分布式呢？三个阶段。第一个请同学们注意。以前。那说穿了就是一整套里面，这个是Java应用程序application，这个是我们的MYSQL，都在一块O吧，一家人。

没问题吧，没有听说过你自己跟你自己写一个借条，自己跟自己借钱的吧，这就不说了，但是随着我们的系统的发展，慢慢的啊变了。这个模式，那么就是我们的一对一啊，那接下来同学们。我们继续，那这个模式开始呢，有些变化，因为慢慢的随着我们的业务的增多，咱们的数据库啊，一定要进行分库，那可能Java程序。还有可能是一份都在一块，比方说就是idea里面就一个工程，好我们的鼓励的商城，或者是我们的。摇的在线教育系统，或者是我们的金融系统等等，随便啦，那接下来不好意思啊，这个时候可能往下面我们直接连的数据库。现在通过分库了以后，可能会形成两个，那慢慢的啊，开始呢，形成了我们的一对多。

也就是说一套应用程序可能会连多个库，比如说啊，最经典的这就是淘宝上的买家库卖家库肯定要分开嘛，再说白一点，我们的下订单。我们的库存，那么这个时候是不是可以允许程序？多数据源多括好这儿也认了，关键到后面怎么会干到分布式呢？因为我们的微服务架构出来以后，我们的系统变化了，可能是。订单拈。连的是我们的订单库，这么说能跟上，那这个时候好了，我们呢，专库专连，那么现在就变成了这样的一种情况，那就麻烦了同学们。假设我们经常碰上的啊，下订单减库存做支付，那么这个时候可能是订单库。

物流库存库，还有金融账户和我们的支付的库，是三个不同的数据库，甚至布在三个不同的机房，那这个时候同学们，我们是不是牵扯到。多数据源多中心的跨库的调用啊，有可能我希望你是下单成功，新增一条订单记录啊，减法扣掉一个库存，减法一切成功了，我们再扣减我们的支付金额，那么兄弟们这三个操作连三个不同的库，说穿了这个时候这三个是不是相当于说是一个整体，物理上他们可能是三个不同的数据库，但是逻辑上是统一的一个事物，牵扯到这样全局的跨数据库的，多数据源的统一调度，这个就是我们的分布式事物。的前身和雏形，以及我们问题的痛点，那么兄弟们根据前面你就会明白。

一对一，一对多，多对多，而且这块有可能还一些复杂的业务，还会什么，这个会连到这儿，这个也会连到这儿，不奇怪，OK好了，那么同学们，我们分布式之后。来看一个这么一个情况。先说图，后说字。用户购买商品的业务逻辑分为三个微服务支撑business，我们的业务逻辑，比方说下单，下单有些呢，他们是要串联啊，下单成功了库存，然后这个，而我们这种情况下呢，是并行下单减库存，请大家看。库存库、订单库、账户库，仓储服务，对给定的商品，这个时候要进行扣除订单，根据采购的需求新增创建一个订单账户，要这样，那么牵扯到兄弟们。

123不废话，绝对是多个数据库的共享、跨库和协调调度，那么这个时候说白了，以前的单体应用被拆分成微服应用，这个是三个Java，这个是三个数据库。那么。原先的三个模块被拆分成三个独立的应用，分别使用三个独立的数据库，业务操作需要调三个服务来完成，因此每个服务内部的数据一致性。都只能由本地的事物来保证。123。但是这三个要一起成功，或者这三个要一起失败，统一的协调调度，我们是不是需要有个大哥全局的数据这些问题呢？就需要有人来兜底，来担保，否则此时这样一种状况状况，三个数据库各自为战，他们的全局数据一致性问题是没有办法得到保证的，那么我们这样的微服架构是失败的。

好那么一句话，一次业务操作需要跨多个数据源或多跨多个系统进行远程的调用，就会产生分布式的数问题。说穿了，这哥们来解决的痛点就是全局数据一致性问题的保障。OK，那么同学们这个就先提出来什么是分布式事物的问题，我们先打个引子。