1 传统的分布式事务 基于数据库支持的xa两阶段提交事务
缺点 ：
1性能差，再xa 两阶段提交锁一直占有，协议是阻塞性协议。
2可靠性低，如果xa协调程序宕机。所有的事务都阻塞
为了提升性能，采用强一致性降低到最终一致性的思路。将面向资源的事务，提升到面向业务的事务。降低锁的粒度。提高并发度，
出现了几种理论
1saga 理论。将长事务分割成短事务，事务采用补偿机制，进行保持最终一致性。
特点
适应场景 1必须支持幂等性 2场景的独立性
1性能高 2 业务改造成本低3 无法解决事务的隔离性
阿里的seata框架，实现了saga模式。
https://seata.io/zh-cn/docs/user/saga.html参考
saga实现理论
https://www.jianshu.com/p/e4b662407c66
2tcc 理论
Seata 框架把每组 TCC 接口当做一个 Resource，称为 TCC Resource。
将底层的资源模型，提升到业务层次。
TCC 模型的隔离性思想就是通过业务的改造，在第一阶段结束之后，从底层数据库资源层面的加锁过渡为上层业务层面的加锁，从而释放底层数据库锁资源，放宽分布式事务锁协议，将锁的粒度降到最低，以最大限度提高业务并发性能。
采用数据库锁与业务加锁的方式结合。由于业务加锁的特性不影响性能，因此，尽可能降低数据库锁粒度，过渡为业务加锁，从而提高业务并发能力。
1阶段 预占资源。
2阶段，决定提交还是回滚
特点
1性能高2解决了隔离性的问题（二阶段只操作自己占用的资源。与其他事务无关，避免了并发性问题）
3 业务的改造成本比较高
tcc 理论 https://www.infoq.cn/article/G33hCC-QoSJPlkt4e64E 理论 讲解了相对xa协议为啥提升了性能
https://juejin.im/post/5bf201f7f265da610f63528a具体例子
saga 模式
也是分2阶段提交。1阶段，申请并占有全局锁后会提交本地事务和事务日志 2阶段决定回滚还是提交
用全局锁实现了事务写隔离 默认读未提交事务隔离级别。可以实现 读已提交事务隔离。
如果应用在特定场景下，必需要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
SELECT FOR UPDATE 语句的执行会申请全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。
出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。
参考https://seata.io/zh-cn/docs/overview/what-is-seata.html
特点
1实现了事务的隔离性
2把每个数据库被当做是一个 Resource
3应用层基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性；
3相对其他性能差。5次rpc通信
分布式三大理论的总结
https://www.jianshu.com/p/917cb4bdaa03
感谢以上各位文章的作者无私的风险。
网友评论