分布式事务解决方案

我们都知道传统的本地事务通过Spring的@Transactional就可以实现
当我们下订单的时候 更改订单状态，扣减库存都在一个方法中写的，通过@Transactional就可以做到本地事务的回滚或者提交

但是随着我们业务的发展，我们的会吧库表分开, 吧一个完整的数据库现在拆分成多个库，一个订单支付的操作设计到2个操作 一个是 支付订单  update 状态 ,一个是减库存,现在在一个方法中操作了2个库   这种场景 使用@Tr 搞定么

碰到这种场景我们该怎么办呢，这种只是跨库的分布式事务
单系统跨库 事务也算是分布式事务， 因为此时用@Transactional 是不能帮我们解决跨库事务的，此时用两阶段提交协议

两阶段提交这个协议有一个角色的划分 会抽象出来一个事务协调者和参与者,
我们这种跨库问题在哪里，订单支付我们想要达到效果 就是订单状态改为已支付，减少库存，我们希望这2个操作要么同时成功 要么同时失败，这是一个整体的事务

如果不用事务的时候就可能出现订单更改状态成功，但是库存扣减失败
库存扣减失败的原因有很多 比如说库存不够减，库存库挂了，这样就会会造成2边事务不一致,一般来说出现事务不一致就是第一步状态修改为支付成功了 第二部 减库存失败了

我们引入两阶段提交这种协议帮我们解决这种跨库的事务是怎么去做的 ,我们首先会引入事务管理器（中间协调者），然后第一步就是我执行完sql 但是我不提交  我只是吧结果告诉给了中间协调器，中间协调者收到以后，如果这些都成功了，事务管理者正常通知所有库提交事务
第一阶段有个专业的名词叫做预提交，你sql执行完毕不提交就叫预提交，他并没有真正的落地到数据库，只是吧执行的结果告诉给了资源协调器，吧资源锁住
如果第一个阶段2个阶段都成功  事务管理器通知所有数据库 去提交事务
第一个阶段有一个报错 第二个阶段就做rollback操作  这就是两阶段提交的底层思想 

事务管理器通知第二个阶段每个事务 commit/rollback,会不会可能出现这种情况
我通知订单库的时候成功了
我通知库存库的时候失败了
感觉也不能100%的解决分布式事务的问题
分布式事务不可能100%解决。第二阶段通知过程中可能因为网络原因导致部分节点通知失败。只可能尽量提高成功概率 这种情况会触发重试机制，或者短信通知
对应的运维人员进行补偿
如果不用两阶段提交.最可能出现的情况就是你执行订单更改状态正确
操作第二个的时候减库存失败了,我们的两阶段提交是不是就可以解决这种
情况
我们两阶段提交协议大大的提高了事务提交的概率