springCloud-分布式事务理解

分布式事务猜想

我们都知道，使用分布式时，分布式事务是很重要的，所以会使用分布式事务
设想一下，既然是分布式事务了，那么基于对事务的理解，是否可以从以下几个方面理解分布式事务呢
前提：服务分为A和B，事务管理器为服务C

第一种分布式事务思想猜想

前提：服务A发起一个事务，提交了一条sql，同时调用服务B，服务B发起了一个事务，同时提交了一条sql，但是都没有提交事务
后续：服务B跟服务A执行完sql都没有报错，就认为可以提交了
思考：此时两个服务的事务都挂着，怎么去进行统一提交呢
解决：单独部署一个服务C，服务A跟服务B执行完sql，都告诉服务C说sql已经执行完毕，那服务C就挨个告诉服务A与服务B，可以提交事务了，服务A与服务B分别把再把自己的事务提交到数据库
优点：强CP，强一致性，事务交给数据库管理，减少了系统维护成本
缺点：占用数据库资源，所有调用链的sql没有执行完毕，此链上的事务就不能提交

第二种分布式事务思想猜想

前提：服务A和服务B执行自己的sql，提交事务，并写出来相应的回滚sql，就像平常写sql脚本的回滚脚本似的
后续：服务A和服务B执行完自己的sql，发现没有报错，需要告诉此执行链上的所有服务说没问题了，不用执行回滚脚本
解决：需要部署一个服务C，用来接收这些调用链上的sql执行结果，并分别告诉此执行链上的服务，用不用回滚
优点：强AP，保证最终一致性，不需要依赖数据库，自己管理脚本，开发者拥有最高权限，人为可控
缺点：不支持最终一致性，弱CP，受网络抖动影响比较大

分布式事务server猜想

经过上边两个猜想，可以得出，需要有一个分布式server去管理这些事务，那么可以想出下边两种解决方案

1. 单独部署一个server，用来管理这些事务，
   优点：统一管理，方便维护
   缺点：如果server宕机，就无法提供服务
2. 每个调用链的第一个节点作为事务管理的server，用来接收各个节点的sql执行结果，并返回提交还是回滚
   优点：每个服务都可以是事务管理的server，不怕宕机
   缺点：实现起来比较费劲

分布式事务分类

分布式事务分以下几种：
XA
AT
TCC
SOGA
网上发布的带有很专业的名词的文章，大伙有可能看不懂，接下来就用白话文讲述一下

两段式提交协议

其实这个协议没什么神秘的，就跟咱们自己写代码，开启事务，执行sql，提交事务是一样的
只不过mysql中的两段式提交也可以叫做三段式提交，它分为了，CanCommit、PreCommit、DoCommit 三个步骤，感兴趣者可以网上搜一下

XA

跟上边第一种分布式事务思想猜想原理差不多，只不过这个XA模式是需要数据库去支持的，本质上和普通的事务没什么区别
最大区别： 可以自定义事务ID，拿到数据库的事务ID，就可以知道自己执行的sql属于哪个事务，就可以对事务进行回滚或者提交操作了

AT

与XA最大的区别就是，回滚脚本由框架去生成

TCC

这个不理解的，可以看下下边的SOGA
TCC这个可能有点不好理解，平时写sql脚本，一条sql对应一句回退脚本，或者多条sql对应语句回退脚本，那么这个TCC怎么搞出来这么多花样呢
其实是应用场景的不同，才出现了TCC，举一个场景看一下可能就理解了
恢复库存 <-- 锁单减库存 -> 创建订单

1. 顾客购买商品，程序进行锁单减库存（try）
2. 顾客点击下单，创建订单成功（confirm）
3. 顾客取消，恢复库存（concel）
   也就是说，这种需要锁库存的，或者代码业务逻辑需要预留资源的，需要阶段式的操作，才适合TCC这种场景
   TCC全名（try-confirm-cancel），其实这个名字不是针对技术上，而是针对业务逻辑才起的名字

SOGA

这个就跟上边的第二种分布式事务思想猜想差不多，但是与TCC不同的是，一个sql执行语句对应一个回退脚本

存在问题

由于微服务天生依赖网络，对网络比较敏感，所以会出现以下问题

悬挂

空回滚

幂等性

总结

总结一下上边说的废话，其实分布式事务没那么难理解，看了我这篇白话文之后，再去看网上那些专业词汇比较多的文章就容易理解了

大总结

其实不管是那种分布式事务的实现，都有一个事务ID的，所以很容易就联想到微服务链路追踪