关于分布式事务
关于分布式事务
分布式事务产生的背景
在微服务环境下，因为会根据不同的业务会拆分成不同的服务，比如会员服务、订单服务、商品服务等，让专业的人做专业的事情，每个服务都有自己独立的数据库，并且是独立运行，互不影响。
比如：
服务与服务之间通讯采用RPC远程调用技术，但是每个服务中都有自己独立的数据源，即自己独立的本地事务。两个服务相互通讯的时候，两个本地事务互不影响，从而出现分布式事务产生的原因。
传统项目中：多数据源就是在一个项目中，有两个jdbc连接
环境搭建： 分包或者注解方式
案例：
在电商系统中，下单和扣库存如何保持一致？
比如:用户先下单后，扣库存失败，那么将会导致超卖；如果下单不成功，扣库存成功，那么会导致少卖。这两种情况都会导致运营成本增加，在严重情况下需要赔付。
订单服务和库存服务 是个RPC远程调用过程
订单与库存服务不在同一个JVM（分布式），相互的数据库都是独立的，每个独立的数据源中都有自己独立的事务，该事务成为本地事务。本地事务有效范围在同一个jdbc里面（同一个事务管理器 ）
下单失败了 但是库存成功了 怎么个回滚法
同理 下单成功 库存失败了呢！这个不属于分布式事务！ 拿到错误的返回结果 进行处理就ok啦
我在调用接口时候 掉完了 然后我错了
因为订单服务和库存服务不在同一个jvm中，数据库都是独立的。每个独立的数据库源都有自己独立事务，该事务成为本地事务。
本地数据源有效范围 ： 同一个jdbc连接 或者同一个事务管理器
而多数据源 不同的 多个jdbc连接
每个独立的事务，核心思想 全局事务 一个协调者
项目中 两个不同的jdbc，连接相同的数据库。 两个jdbc事务不能相互关联！！
上图中 的结果是 下单失败了（事务回滚） 但是库存却减少了！
下面这种情况：
不是分布式事务问题， invenReduction() 出错 调用时候 会获取到错误的返回信息 执行相应的业务逻辑 不会产生分布式事务问题 这种场景 人为可控 没问题
题外话： 人工补偿 自动补偿（MQ）
传统项目一般不会出现 分布式事务问题，但是多数据源情况会有可能产生！