Spring Cloud Alibaba---之分布式事务

学习了下分布式事务的一些解决方案，进行记录。
1.什么是事务
事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。
1.1什么是分布式事务？
指在多个服务或多个数据库的情况下，产生的事务。情况分别为：
1）跨数据源的分布式事务
2）跨服务的分布式事务
3）综合情况
说道事务，就离不开事务的特性 ACID：
1）原子性（Atomicity），可以理解为一个事务内的所有操作要么都执行，要么都不执行。
2）一致性（Consistency），可以理解为数据是满足完整性约束的。
3）隔离性（Isolation），指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。
4）持久性（Durability），指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。
2. 分布式事务基础理论
与本地事务不同的是，分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同机器上，相互之间通过网络交互。不能因为有一点网络问题就导致整个系统无法提供服务，网络因素成为了分布式事务的考量标准之一。因此，分布式事务需要更进一步的理论支持，接下来，我们先来学习一下分布式事务的CAP理论。

2.1 CAP理论
CAP 是 Consistency、Availability、Partition tolerance 三个单词的缩写，分别表示一致性、可用性、分区容忍性。
C：Consistency 一致性(强一致性)
A：Avaliablity 可用性(实时可用，即使返回错误信息)
P：Partition Tolerance 分区容错性

在所有分布式事务场景中不会同时具备 CAP 三个特性，因为在具备了P的前提下C和A是不能共存的
CAP的组合方式
所以在生产中对分布式事务处理时要根据需求来确定满足 CAP 的哪两个方面。
1.AP
放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。
2.CP
放弃可用性，追求一致性和分区容错性，zookeeper 其实就是追求的强一致，又比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。
总结
CAP 是一个已经被证实的理论，一个分布式系统最多只能同时满足：一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它可以作为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 N 个 9（99.99…%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证 P 和 A ，舍弃 C 强一致，保证最终一致性。

2.2 BASE 理论
1.强一致性和最终一致性
CAP 理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项，其中AP在实际应用中较多，AP 即舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，比如前边我们举的例子主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和 CAP 中的一致性不同，CAP 中的一致性要求 在任何时间查询每个结点数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内每个结点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。
2.Base 理论介绍
BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent （最终一致性）三个短语的缩写。BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。

3.分布式事务解决方案
有了以上的理论基础，解决分布式事务也就有了相应的方案了。

3.1方案一之—分阶段提交（ 2PC）
1.P阶段：准备阶段协调者会给各参与者发送准备命令，你可以把准备命令理解成除了提交事务之外啥事都做完了。同步等待所有资源的响应之后就进入第二阶段
2.C阶段:根据所有的资源响应，决定是提交操作，还是回滚操作
如下图的流程

很明显的会发现一个问题，这里就会有锁的机制存在，等待响应的时候，会等待所有的资源都响应后，才会触发操作。明显，这样的效率是不被接受的。

3.2方案二之—TCC
T: try 对于资源的准备
C:Commit 数据的提交
C:Cancel 数据的回滚
也分为两个阶段
第一阶段:执行本地事务，并返回结果。
第二阶段:根据第一阶段的结果，判断第二阶段的做法。提交或者回滚

这个方式的性能上会比第一种提升，不需要进行等待其他事物也都处理完成。 但是它的缺点是自己要写事物的代码。 如果第一个事物失败了，就要自己写代码通知事件A失败了，进行回滚。对业务代码入侵太多了，显然也不是值得推荐的

3.3方案三之—可靠消息（MQ）
利用MQ，进行两个事物的再次确认。
比如，A事物通知B，B处理完成后，消息放入MQ告知A是成功了还是失败了需要回滚。

3.4方案四之—AT模式
比如需要进行扣减库存和下单在两个服务时
第一个服务扣减库存，当执行 update tb_stock set stock= stock - 1 where id = 1时，(例如 stock初始值为10)
它的内部就会类似于undo日志进行镜像的记录
select * from tb_stock where id = 1 --> before image
此时镜像里面的值为10
执行完update的SQL后，会再次执行查询放入到镜像中，类似于 redolog
select * from tb_stock where id = 1 -->after image
此时，镜像里面的值为 8

执行第二个事务的时候，就会先根据镜像里面信息得知是成功还是失败了，进行对应的处理。
这个比第二个好处就是，不需要写入太多的入侵代码了。

3.5方案五之—Seata
阿里的Spring Cloud Alibaba 推出了 Seata的解决方案
先引入几个关键词
TC:(Transaction Coordinator) – 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚（TM之间的协调者）
TM：(Transaction Manager) --事务管理器
定义全局事务的范围：开始全局事务、提交或者回滚全局事务
RM：（Resource Manager） --资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata 有两种分布式事务的实现。AT及TCC
AT是关注多db访问的数据一致性
TCC关注的是横向扩展资源

最大努力通知其实只是表明了一种柔性事务的思想：我已经尽力我最大的努力想达成事务的最终一致了。