image.png

本地事务与分布式事务

例如：扣减库存和保存订单是在两个服务中存在的，如果扣减库存后订单保存失败了是不会回滚的，这样就会造成数据不一致额情况，这其实就是我们所说的分布式事务的问题

1）事务

数据库事务（简称：事务，Transaction）是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。

事务拥有以下四个特性，习惯上被称为ACID特性

原子性（Atomicity）：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行

一致性（Consistency）：事务应确保数据库的状态从一个一致状态转变为另一个一致 状态。一致状态是指数据库中的数据应满足完整性约束。除此之外，一致性还有 另一层语义，就是事务的中间状态不能被观察到（这层语义也有说应该属于原子性）

隔离性（Isolation）：多个事务并发执行时，一个事物的执行不应影响其他事务的 执行，如同只有这一个操作在被数据库所执行一样

持久性（Durability）：已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时 ，此操作将不可逆转

image.png
image.png

2）本地事务

起初，事务仅限于对单一数据库资源的访问控制，架构服务化以后，事务的概念延伸到了服务中，倘若将一个单一的服务操作作为一个事物，那么 整个服务操作只能涉及一个单一的数据库资源，这类基于单个服务单一数据库资源访问的事务，被称为本地事务（Local Transaction）

在一个微服务里面所有业务方法操作的且是同一个数据库资源，这就是收到本地事务控制
image.png
Spring的声明式事务就是 很好的本地事务解决方案！ 加上@Transaction注解
**

3）分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败，本质上来说分布式事务就是为了保证不同数据库的数据一致性
最早的分布式 事务应用架构很简单，不涉及服务间的访问调用，仅仅是服务内操作涉及到对多个数据库资源的访问
image.png
当一 个服务操作访问不同的数据库资源，又希望对他们的访问具有事务特性时，就需要采用分布式事务来协调 所有的事务参与者。
对于上面介绍的分布式事务应用架构，尽管一个服务操作会访问多个数据库资源 ，但是毕竟整个事务还是控制在单一服务的内部，如果一个服务操作需要调用另外一个服务，这时的事务就需要跨越多个服务了，这种情况 下，起始于某个服务的使用在调用另一个服务的时候，需要以某种机制流转到另一个服务，从而使被调用的服务访问的资源也自动加入到该事务当中来。下图反映了 这样一个跨越多个服务的分布式事务
image.png
如果将上面这两种场景（一个服务可以调用多个数据库资源，也可以调用其他服务）结合在一起，对此进行延伸，整个分布式事务的参与者将会组成如下图所示的属性拓扑结构。在一个跨服务的分布式十五中，事务的发起者和提交均系同一个，它可以使整个调用的客户端们也可以是客户端最先调用的那个服务。
image.png
较之基于单一数据库资源访问的本地事务，分布式事务的应用架构更为复杂，在不同的分布式应用架构下，实现一个分布式事务亚奥考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等 、实现机制也是复杂多变

只要跨多个微服务，或者跨多个数据库，都属于分布式事务的场景、分布式事务的方法不受到@Transactional注解的控制

CAP定理和BASE理论

CAP定理

image.png

CAP定理是在1998年加州大学的计算机科学家踢出，分布式新系统有三个指标
Consistency 一致性
Availability 可用性
Partition tolerance 分区容错（容错性）
他们的第一个字母分别是C、A、P，这三个指标不可能同时做到。这个结论叫做CAP定理
一般要求P必须要成立，A和C只能顾及一个，也就是说，我们只能满足AP或者CP。

分区容错 Partition tolerance

大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个去，他们之间可能无法通信
image.png
上图中，G1和G2是两台跨区的服务器，G1向G2发送一条消息，G2可能无法收到。系统设计的时候，必须考虑到这种情况。
一般来说，分区容错无法避免，因此可以认为CAP的P总是成立，CAP定理告诉我们，剩下的C和A无法同时做到

可用性 Availability

Availability中文叫做可用性，意思是只要收到用户的请求，服务器就必须给出回应。用户可以选择向G1或G2发起读操作。不管哪台服务器，只要收到请求，就必须告诉用户，到底是V0还是V1，否则就不满足可用性
image.png

一致性 Consistency

Consistency中文叫做一致性，意思是，写操作之后的读操作，必须返回该值
举例来说，某条记录是v0，用户向G1发起一个写 操作，将其改为v1
image.png
问题是，用户有可能向G2发起读操作，由于G2的值没有发生变化，因此返回的是v0.G1和G2读操作的结果不一致，这就不满足一致性了。
image.png
为了让G2也能变成v1，就要在G1写操作的时候，让G1向G2发送一条消息，要求G2也改成v1.
image.png

一致性和可用性的矛盾

一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。
如果保证G2的一致性，那么G1必须在写操作时，锁定G2的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2不能读写，没有可用性。
如果保证G2的可用性，那么势必不能锁定G2，所以一致性不成立。
综上所述，G2无法同时做到一致性和可用性。系统设计时只能选择一个目标，如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

2）BASE理论

BASE：全称：Basically Available（基本可用），Soft state（软状态），和Eventually consistent（最终一致性）三个短语的缩写，来自ebay的架构师提出。BASE理论是对CAP中一致性和可用性权衡的结果。其来源对大型互联网分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是：
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的 方式来使系统达到最终一致性（Eventual consistency）

Basically Available(基本可用)

什么是基本可用呢？ 假设系统出现了不可预知的故障，丹还是能用，相比较正常的系统而言：
响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以再1秒作用返回结果
功能上的缺失，在一个点上网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促销期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

Soft state（软状态）

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延迟

Eventually consistent（最终一致性）

系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到 一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。

分布式解决方案

1）基于XA协议的两阶段提交

首先我们来简要看下分布式事务处理的XA规范：Spring整合JTA
image.png

可知XA规范中分布式事务有AP、RM、TM组成：
其中应用程序（Application Program，简称AP）：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。
资源管理器（Resource Manager，简称RM）：RM管理计算机共享的资源，许多软件都可以去访问这些资源，资源包含比如数据库、文件系统、打印机服务器等
事务管理器（Transaction Manager，简称TM）：负责管理全局事务，分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。

二阶段协议:
**
第一阶段TM要求所有的RM准备提交对应的事务分支，询问Rm是否有能力保证成功的提交事务分支，RM根据自己的情况，如果判断自己进行的工作可以以被提交，那么就对工作内容进行持久化，并给TM回执OK；否则给TM回执NO。RM在发送了否定答复并回滚了已经的工作后，就可以丢弃这个事务分支信息了。

第二阶段TM根据阶段1各个RM prepare的结果，绝顶是提交还是回滚事务。如果所有的RM都prepare成功，那么TM通知所有的RM进行提交；如果有RM prepare回执NO的话，则TM通知所有RM回滚自己的事务分支。

也就是TM与RM之间是通过两阶段提交协议进行交互的

优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域
（其实也不能100%保证强 一致）
缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景

2）TCC补偿机制

TCC其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段
Try阶段主要是对业务系统做检测及资源预留
Confirm阶段时，默认Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功
Cancel阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
image.png
例如：A客户使用携程APP到东方航空和北京航空去订票，思路大概是：

  1. 票：广州->北京    东方航空：北京->伤害        北京航空:上海->北京
  3. 没加航空公司的订票流程
  4. 1.Try：预留机票座位（返回预留 成功或失败的结果）
  5. 2.Confirm：如果两家公司Try 返回的结果都是预留成功，继续调用两家公司的Confirm（下订单）
  6. 3.Cancel：只要其中一家公司Try返回的结果预留失败，则统一两家公司的Cancel（把之前预留成功的座位回退）

优点：相比两阶段提交可用性比较强

缺点：数据的一致性要差一点。TCC属于应用层的一种补偿方式，所以需要策划给你许愿在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理

3）消息最终一致性(*)

消息最终一致性应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路来源于ebay。我们可以从下面的流程 图中看出其中的一些细节：
image.png
基本思路就是：
消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重新执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者是失败的消息再发送一遍，如果有靠谱的自动对账补涨逻辑，这种方案还是非常实用额

这种方案遵循BASE理论，采用的是最终一致性比较适合实际业务场景，即不会出现向2PC那样复杂的实现（当调用链很长的时候，2PC的可用性是非常低的），也不会像TCC那样可能出现确认或回滚不了的情况

优点：一种非常经典的实现，避免了分布式事务，实现了最终一致性

缺点：消息表会耦合到业务系统中

4）MQ事务性消息(了解)

image.pngMQ的解决方案需要该类型的MQ能够有事务消息的情况下进行；当下只有RocketMQ能做到，所以基于MQ的分布式事务解决方案中的MQ都是说的RocketMQ

RocketMQ通过事务性消息来实现本地事务与MQ消息的原子性、一致性和可靠性；而远程事务的处理是尽可能保证（上述案例中，订单生成的操作尽可能100%成功），如果处理失败还是需要人工介入的。

Seata简介

分布式事务框架很多：tcc-transaction、Hmily、ByteTCC、myth、EasyTransaction、tx-lcn、seata等等框架，这里有一篇关于这些框架压测的测试报告【不包括seata】：http://springcloud.cn/view/374 ，可以了解下 。
这里我们采用seata来实现分布式事务。
2019 年 1 月，阿里巴巴中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback），和社区一起共建开源分布式事务解决方案。Fescar 的愿景是让分布式事务的使用像本地事务的使用一样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。
Fescar 开源后，蚂蚁金服加入 Fescar 社区参与共建，并在 Fescar 0.4.0 版本中贡献了 TCC 模式。
为了打造更中立、更开放、生态更加丰富的分布式事务开源社区，经过社区核心成员的投票，大家决定对 Fescar 进行品牌升级，并更名为 Seata，意为：Simple Extensible Autonomous TransactionArchitecture，是一套一站式分布式事务解决方案。
Seata 融合了阿里巴巴和蚂蚁金服在分布式事务技术上的积累，并沉淀了新零售、云计算和新金融等场景下丰富的实践经验。

Seata简介

Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
https://seata.io/zh-cn/

解决分布式事务问题，有两个设计初衷
对业务无侵入：即减少技术架构上的微服务化所带来的分布式事务问题对业务的侵入 高性能：减少分布式事务解决方案所带来的性能消耗
Seata目前有三种分布式事务实现方案：AT、TCC及SAGA

  • AT模式主要关注多 DB 访问的数据一致性，当然也包括多服务下的多 DB 数据访问一致性问题2PC-改进
  • TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调用的一致性问题
  • Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

Seata模式说明

1）AT模式

Seata AT模式是基于XA事务演进而来的一个分布式事务中间件，XA是一个基于数据库实现的分布式事务协议，本质上和两阶段提交一样，需要数据库支持，Mysql5.6以上版本支持XA协议，其他数据库如Oracle，DB2也实现了XA接口。

image.png
事务协调器Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
事务管理器Transaction Manager（TM）： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
资源管理器Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

image.png

一阶段

在一阶段，Seata会拦截“业务SQL”，首先解析SQL语义，找到“业务SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务SQL”更新业务员数据，在业务数据更新之后再将其保存成after image，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。任何提交的业务数据的更新一定有相应的回滚日志存在

image.png
基于这样的机制，分支的本地事务便可以在全局事务的第一阶段提交，并马上释放本地事务锁定的资源；这也是Seata和XA事务的不同之处，两阶段提交往往对资源的锁定需要持续到第二阶段实际的提交或者回滚操作，而有了回滚日志之后，可以在第一阶段释放对资源的锁定，降低了锁范围，提高效率，即使第二阶段发生异常需要回滚，只需找对undolog中对应数据并反解析成sql来达到回滚目的。
同时Seata通过代理数据源将业务sql的执行解析成undolog来与业务数据的更新同时入库，达到了对业务无侵入的效果。

二阶段提交

二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。
image.png

二阶段“回滚”

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和“after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。
image.png

2）TCC模式（了解）

2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。TCC 模式通常用于非关系型数据库的分布式事务的实现，作为AT模式的补充。可以与AT模式混合使用。
Seata也针对TCC做了适配兼容，支持TCC事务方案，原理前面已经介绍过，基本思路就是使用侵入业务上的补偿及事务管理器的协调来达到全局事务的一起提交及回滚。
image.png