文章知识来源主要来源于：赵俊夫先生的博客 以下为原文链接
https://blog.csdn.net/u011177064/category_9572944.html
1：什么是事务，什么是ACID
首先，提到分布式事务，咱们得明白什么是事务（Transaction）
事务应该具有4个属性：
原子性(atomicity)、一致性(consistency)、隔离性(isolation)、 持久性(durability)
这四个属性通常称为ACID特性。
特别注意
原子性 与 一致性关系特别紧密
原子性 是 过程
一致性 是 结果
例子：
张三有300元，李四有500元，张三转账100给李四，李四又转回50给张三，
最后张三有250元，李四有550元。
原始状态-- 张三有300元，李四有500元
操作-- 张三转账100给李四，李四又转回50给张三
结果-- 张三有250元，李四有550元
原子性：一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。
张三转账100给李四，李四又转回50给张三”这套操作，要么全做，要么不做。
一致性：事务必须是使数据库从一个一致性状态变到另一个一致性状态。
即如果“操作”发生，那么“结果”就是“张三有250元，李四有550元”；
而如果不发生，则“结果”是 “张三有300元，李四有500元”；
在这件事上，不允许出现其他“结果”。
隔离性：一个事务的执行不能被其他事务干扰。
即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，
并发执行的各个事务之间不能互相干扰。
在我们这个事务中，假如在做“张三转账100给李四，李四又转回50给张三”
这个过程中，突然有个王五给张三转了100元，那么就干扰了我们这个事务的结果，
在数据库中，通过锁机制来让有资源冲突的事务不能并行，
即王五的转账必须等我们当前这个事务执行完有结果后才能开始。
持久性： 指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。
按照字面就很好理解了，我们对数据进行改变后，就保存了，
除非有其他正常操作来改变这个值，不然这个值就永久不变了。
2：什么是分布式事务
1：刚性事务：遵循ACID原则，强一致性。
2：柔性事务：遵循BASE理论，最终一致性；
与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。
分布式事务是指在分布式的环境下实现事务（目前主要是讲柔性事务），那什么是分布式环境呢？即跨服务器、跨数据库的环境
而之前提到的示例，非分布式事务（本地事务）可以看成整个示例在同一个数据库里执行。
在分布式环境下，可能不同用户的余额按照规则被放到不同的数据库里，
可能交易服务器和账户服务器也不在同一个服务器中。
本地事务的实现逻辑是这样的：
库A 开启事务-->库A "张三转账100给李四" -->库A“李四又转回50给张三”
库A 提交/回滚事务
而到了分布式环境：（以XA方案举例说明分布式事务）
库A 开启事务-->库A 张三扣减100 -->库B 开启事务 --> 库B 李四增加100
如果整个事务执行成功， 库A 提交事务 & 库B 提交事务
如果整个事务执行失败， 库A 回滚事务 & 库B 回滚事务
3：分布式事务解决方案
AT 模式是一种无侵入的分布式事务解决方案，在单机数据库事务上扩展出对于分布式的支持：
它的实现主要通过对执行SQL进行解析，
把要操作的数据保存操作前操作后两个版本（每个库中），最终根据整个事务的成败，来确定最后的数据（每个库中）应该是怎样。
TCC模式是一种逻辑上的分布式事务，不单依附在数据库事务上：
它需要每个事务参与者实现 Try、Confirm 和 Cancel 三个操作，即自行实现事务的准备、提交、回滚操作，
然后TCC来从整体角度去统一调用每个事务参与者的 这三个 实现，从而达成分布式的事务。
Saga模式 是一种补偿协议：
在 Saga 模式下，分布式事务内有多个参与者，
每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
Saga 模式适用于业务流程长且需要保证事务最终一致性的业务系统，
Saga 模式一阶段就会提交本地事务，无锁、长流程情况下可以保证性能。
XA模式是分布式强一致性的解决方案，但性能低而使用较少：
需要有一个[全局]协调器，每一个数据库事务完成后，进行第一阶段预提交，并通知协调器，把结果给协调器。
协调器等所有分支事务操作完成、都预提交后，进行第二步；第二步：协调器通知每个数据库进行逐个commit/rollback。
4：Seata 分布式事务框架
Seata 是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。
Seata 支持 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。
图解链接：
https://www.sofastack.tech/blog/seata-distributed-transaction-deep-dive/
5：Seata AT模型
特点：无侵入
用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，
Seata 框架会自动生成事务的二阶段提交和回滚操作。
一阶段：
Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，
在业务数据被更新前，将其保存成“before image”，
然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再
将其保存成“after image”，最后生成行锁。
以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
二阶段提交：
二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库，
所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。
二阶段回滚：
Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。
回滚方式便是用“before image”还原业务数据；
但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，
如果两份数据完全一致就说明没有脏写，可以还原业务数据，
如果不一致就说明有脏写，出现脏写就需要转人工处理。
网友评论