阿里p8架构师总结（别再说你不知道分布式事务了）
阿里p8架构师总结（别再说你不知道分布式事务了）分布式系统会把一个应用拆分为多个可独立部署的服务，服务于服务之间通常需要远程协作才能完成事务的操作，这种分布式系统环境下由于不同的服务之间通过网络远程协作完成的事务被称为分布式事务，例如供应链系统中，订单创建（生成订单、扣减库存、履约通知发货）等Seata 的设计思路是将多个服务器的本地事务组成一个全局事务，下面若干个本地事务，都能满足ACID，最好形成一个整的分布式事务，操作分布式事务就像是操作本地事务一样。在计算机系统中，比较多的是通过关系型数据库来控制事务，这是利用数据库本身的事务特性进行实现的，因为应用主要靠关系型数据库来维持事务，加上数据库和应用都在同一个服务器，所以基于关系型数据的事务又被称为本地事务。分布式事务：分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理者分别位于不同的分布式系统的不同节点之上，且属于不同的应用，分布式事务需要保证这些操作要么全部成功
简介我们都知道 Seata 是一个分布式事务的解决方案，今天我们就来带大家了解一下什么是分布式事务，首先我们先来了解一下基础的知识——事务，我们先来了解一下事务的概念是什么。
基本概念四部分构成—— ACID
- A(Atomic)：原子性，构成事务的所有操作，要么全部执行成功，要么全部执行失败，不会出现部分成功或者部分失败的情况。
- C(Consistency)：一致性，在事务执行前后，数据库的一致性约束没有被破坏，比如，小勇去银行取100块钱，取之前是600，取之后应该是400，取之前和取之后的数据为正确数值为一致性，如果取出100，而银行里面的钱没有减少，要么小勇要笑醒了，这个就没有达到一致性的要求。
- I(Isolation):隔离性，数据库中的事务一般都是并发的，隔离性是只在并发的两个事务执行过程互不干扰，一个事务在执行过程中不能看到其他事务运行过程的中间状态，通过配置事务隔离级别可以避免脏读，重复读等问题
- D(Durability)：持久性，当事务完成之后，事务对数据的更改会被持久化到数据库，且不会回滚
事务分为两部分：本地事务和分布式事务
本地事务：
在计算机系统中，比较多的是通过关系型数据库来控制事务，这是利用数据库本身的事务特性进行实现的，因为应用主要靠关系型数据库来维持事务，加上数据库和应用都在同一个服务器，所以基于关系型数据的事务又被称为本地事务。
分布式事务：
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理者分别位于不同的分布式系统的不同节点之上，且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败，分布式事务就是为了保证在不同服务器上数据库数据的一致性。
Seata 的设计思路是将多个服务器的本地事务组成一个全局事务，下面若干个本地事务，都能满足ACID，最好形成一个整的分布式事务，操作分布式事务就像是操作本地事务一样。
分布式系统会把一个应用拆分为多个可独立部署的服务，服务于服务之间通常需要远程协作才能完成事务的操作，这种分布式系统环境下由于不同的服务之间通过网络远程协作完成的事务被称为分布式事务，例如供应链系统中，订单创建（生成订单、扣减库存、履约通知发货）等
在上图中我们可以看出，只要涉及到操作多个数据源，就会产生事务的问题，我们在实际开发中应该要避免这个问题的出现，但是虽然系统的拓展，应用和应用之间必然会产生应用之间事务的分离，当微服务架构中，主要有MQ和Seata，在了解他们之前，我们先来了解一下分布式事务是怎样组成，以及如何实现的。
分布式事务分布式事务是什么？
分布式事务指的是事务的参与者，支持事务的服务器，资源服务器分别位于分布式系统的不同节点之上，通常一个分布式事物中会涉及到对多个数据源或业务系统的操作。
随着互联网的发展，从之前的单一项目逐渐向分布式服务转换，现如今微服务在各个公司已经普遍存在，而当时的本地事务已经无法满足分布式应用的要求，因此分布式服务之间事务的协调就产生了问题，如果做到多个服务之间事务的操作，能够像本地事务一样遵循ACID原则，成为一个难题，但是在大牛们不断的探索下，终于找到了分布式事务存在两大理论依据：CAP定律和BASE理论
CAP定律CAP定律由一致性(C)、可用性(A)、分区容错性(P)组成，在分布式系统中，不可能同时满足Consistency(一致性)/Availability(可用性)/Partition tolerance(分区容错性) 三个特性，最多只能同时满足其中两项。
- 一致性(C)：在分布式系统中所有的数据备份，在同一时刻保持一致的特性，所有的应用节点访问的都是同一份最新的数据副本。
- 可用性(A): 当集群中一部分节点故障以后，集群整体能够响应客户端的读写请求，对数据更新具备高可用性。
- 分区容错性(P): 如果系统在规定时间限制内不能达成数据的一致性，就表示要发生分区的情况，当前操作需要在C和A之间做出选择，让系统能够在遇到网络故障等情况的时候，任然能够保证对外提供满足一致性或者可用性的服务。
在上图中我们可以看到，当我们用户去购物车里面点击下单结算的时候，首先会经过我们的库存服务，判断库存是否足够，当库存满足，扣减库存以后，我们需要将数据同步到其他服务器上，这一步是为了保证数据的结果的一致性，这个时候如果网络产生波动了，我们的系统需要保证分区容错性，也就是我们必须容忍网络所带来的一些问题，此时想保证一致性，就需要舍弃可用性。
但是如果为了保证高可用性，那么在高并发的情况下，是无法保证在限定时间内给出响应，由于网络的不可靠，我们的订单服务可能无法拿到最新的数据，但是我们要给用户做出响应，那么也无法保证一致性，所以AP是无法保证强一致性的
如果既想要保证高可用又想要保证一致性，必须在网络良好的情况下才能实现，那么解决方法只有一个，那就是需要将库存、订单、履约放到一起，但是这个就上去了我们微服务的作用，也就不再是分布式系统了
在分布式系统中，分区容错性是必须存在的，我们只能在一致性和可用性上取舍，在这种条件下就诞生了BASE理论
BASE理论BASE由 基本可用 (Basically Available)、软状态 (Soft state)和 最终一致性 (Eventually consistent) 三个构建而成，是对CAP中一致性和可用性权衡的结果，来源于对互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，核心四系那个是及时无法做到强一致性，但是每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
- 基本可用： 基本可用是指当分布式系统出现不可预知故障的时候，允许损失部分可用性，但是这里并不是说表示系统不可以用，主要体现为以下几点:
- 响应时间上的损失，在正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户响应的查询结果，但是由于出现故障，查询结果的响应时间增加了1-2秒
- 系统功能上的损失，在正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一单的操作，但是在一些节日大促销购物高峰期的时候，由于网站上购买量的猛增，为了保证系统的稳定性，部分消费者可能会引导到一个临时降级处理的页面或者提示
基本可用的意思是，对于我们的核心服务是可以使用的，其他的服务可以适当地降低响应时间，甚至是进行服务降级处理，在当前中，库存和订单肯定是核心服务，至于我们的发货系统在当时只要保证基本可用就行，它的同步可以慢一点或者延迟更高，等待流量高峰过去以后，在进行恢复。
- 软状态： 软状态是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统不用节点的数据副本之间进行数据同步的过程存在延时
软状态的意思是说，当我们大量下单的时候，扣减库存时，流量激增，这个时候如果大量访问到库存或者订单中，可能会将系统弄垮，这个过程中我们可以允许数据的同步存在延迟，不影响整体系统的使用。
- 最终一致性： 最终一致性强调的是所有数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态，因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不是需要实时保证系统的强一致性。
经过流量高峰期以后，经过一段时间的同步，从中间状态最后变成数据最终一致性，保证各个服务数据的一致性。
二阶段提交(2PC)2PC即两阶段提交协议，是将整个事务流程分为两个阶段，P是指准备阶段，C是指提交阶段。
就好比我们去KCC买冰淇淋吃，那刚好有活动，第二杯半价，但是你是一个人，这个时候刚好有个小姐姐过来，正在考虑买不买冰淇淋吃，这个时候你和她提出了AA，也就会说只有当你和她都同意买这个的时候，才能购买到，如果两个人中有一个不同意那么就不能买这个冰淇淋吃。
阶段一：准备阶段 老板要求你先进行付款，你同意付款完成后，再要求女方付款，女方同意付款完成
阶段二：提交阶段 都付款完成，老板出餐，两个人都吃到冰淇淋
这个例子就组成了一个事务。如果男女双方有一个人拒绝付款，那么老板就不会出餐，并且会把已收取的钱原路退回。
整个事务过程是由事务管理器和参与者组成的，店老板就是事务管理器，你和那个女孩就是参与者，事务管理器决策整个分布式事务在计算机中关系数据支持两阶段提交协议：
- 准备阶段(Prepare phase)：事务管理器给每个参与者发送 Prepare 消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo 日志，此时事务没有提交。
undo日志是记录修改前的数据，用于数据库回滚
Redo 日志是记录修改后的数据，用于提交事务写入数据文件
- 提交阶段(Commit phase)：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送(Rollback) 消息，如果收到参与者都成功，发送(Commit) 参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的资源。
成功提交：
事务管理器向所有参与者发送事务内容，询问是否准备好了，等待参与者的响应，各个参与者事务节点执行事务操作，并将 Undo和Redo 信息记入事务日志中。如果参与者成功执行事务操作，反馈事务管理器YES操作，表示事务可以执行，假如协调者从所有的参与者或得反馈都是Yes响应，那么就会执行事务提交。
失败：
假如任何一个参与者向事务管理器反馈了No指令，或者等待超时之后，事务管理器无法接收到所有参与者的反馈响应，那么中断事务，发送回滚请求，事务管理器向所有参与者节点发送RollBack 请求，参与者接收到消息 RollBack 请求后，会利用在阶段一记录的Undo信息执行事务的回滚操作，在完成回滚之后释放事务执行期间占用的资源，参与者在完成事务回滚之后，向协调者发送ACK消息，事务管理器在接受到所有参与者反馈的ACK消息之后，完成事务中断。
3PC 主要是为了解决两阶段提交协议的单点故障问题和缩小参与者阻塞范围。是二阶段提交（2PC）的改进版本，引入参与节点的超时机制之外，3PC把2PC的准备阶段分成事务询问（该阶段不会阻塞）和事务预提交 则三个阶段分别为 CanCommit、PreCommit、DoCommit
CanCommit 询问状态
CanCommit阶段 协调者(Coordinator)会向参与者(Participant) 发送CanCommit消息，询问是否可以执行操作，参与者收到消息后，表示能够执行，会返回给协调者能够执行的(yes)命令
如果参与者不能执行，会返回No命令 释放资源，结束事务。
PreCommit 预提交
PreCommit 阶段如果协调者收到参与者返回的状态值为YES，那么就证明它们都有能力去执行这个操作，那么协调者就会向所有参与者 发送 PreCommit 消息，协调者收到 PreCommit消息后，回去执行本地事务，如果执行成功会将本地事务保存到 undo和redo 后，再返回给协调者YES指令，如果执行本地事务失败，返回协调者No 只要协调者收到一个执行失败，给所有参与者发送中断事务消息，参与者收到消息后，对事务进行回滚操作。
在这个阶段参与者和协调者都引入了超时机制，如果参与者没有收到，协调者的消息，或者协调者没有收到参与者返回的预执行结果状态，在等待超时之后，事务会中断，避免了事务的阻塞。
协调者向参与者发送PreCommit，如果参与者执行成功，返回yes
如果参与者执行失败，只有有一个返回No到协调者，协调者会向参与者发送中断事务的消息，参与者回滚事务。
DoCommit 提交
协调者收到所有参与者返回的状态都是YES，这时协调者会向所有的参与者都发送 DoCommit，参与者收到 DoCommit 后，会真正的提交事务，当事务提交成功后，返回协调者YES状态，表示我已经完成事务的提交了，协调者收到所有参与者都返回YES状态后，那么就完成了本次事务。
如果某个参与者返回No消息，协调者发送中断事务消息(abort)，给参与者们，参与者回滚事务
3PC是2PC的升级版，引入了超时机制，解决了单点故障引起的事务阻塞问题，但是3PC依然不能解决事务一致性的问题，因为在DoCommit阶段，如果由于网络或者超时等原则导致参与者收不到协调者发送过来的 中断事务消息(abort) ，过了这个时间后，
参与者会提交事务，本来是应该进行回滚，提交事务后，会导致数据不一致的问题出现，2PC虽然在网络故障情况下存在强一致性被破坏的问题，但是故障恢复以后能保证最终一致性，3PC虽然有超时时间，解决了阻塞，提高了可用性，但是牺牲了一致性，如果针对网络波动问题导致数据问题这一点上，2PC是优于3PC的
Seata官网：https://seata.io/zh-cn/docs/overview/what-is-seata.html
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
在微服务系统中，一般业务会被拆分成独立的模块，在官方提供的结构图中，我们可以看到当前主要分为三个模块.
- 库存服务：对于商品库存信息进行增加或者减少操作
- 订单服务：根据用户指定商品生成订单
- 账户服务：从用户账户中扣除余额，增加积分，维护地址信息等等
在当前架构中，用户挑选心仪的商品下单后，需要三个服务来完成操作，每一个服务的内部都拥有一个独立的本地事务来保证当前服务数据的强一致性，但是三个服务组成的全局事务一致性就没办法进行保证，那么Seata就是来解决这个问题的。
Seata术语官网地址：https://seata.io/zh-cn/docs/overview/terminology.html
在了解Seata之前，我们先来了解一下 Seata 几个关键的概念：
- TC(Transaction Coordinator)事务协调者：维护全局和分支事务的状态，驱动全局事务提交或者回滚
- TM(Transaction Manager) 事务管理者： 发起者，同时一个RM的一种，定义全局事务的范围，开始全局事务，提交或回滚全局事务。
- RM(Resource Manager) 资源管理器： 参与事务的微服务，管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚
一阶段： 业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段： 提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。
一阶段本地事务提交前，需要确保先拿到 全局锁 。拿不到全局锁 ，不能提交本地事务。拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
在数据库本地事务隔离级别读已提交或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交
如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
Seata执行流程分析：
每个RM 使用 DataSourceProxy 链接数据路，目的是使用 ConnectionProxy ，使用数据源和数据代理的目的是在第一阶段将 undo和业务数据放在一个本地事务中提交，这样就保存了只要有业务操作就一定会有dudo日志，
在第一阶段中，undo存放了数据修改前后修改的值，是为了事务回滚做好准备，在第一阶段完成就已经将分支事务提交了，也就释放了锁资源。
TM开启全局事务开始，将XID全局事务ID放在事务上下文中，通过feign调用将XID传入下游服务器中，每个分支事务将自己的 Branch ID分支事务ID和XID进行关联，
在第二阶段全局事务提交，TC会通知各个分支参与者提交分支事务，在第一阶段已经提交了分支事务，在这里各参与者只需要删除undo即可，并且可以异步执行。
如果某一个分支事务异常了，第二阶段全局事务回滚操作，TC会通知各个分支参与者回滚分支事务，通过XID和Branch-ID找到对应的回滚日志，通过回滚日志生成的反向SQL执行，完成分支事务回滚到之前的状态。
Seata 下载安装下载地址：https://github.com/seata/seata/releases
解压后找到conf目录
我们在启动seata之前，首先要启动nacos，其实也很简单，只需要下载nacos后启动就行，不知道nacos怎么操作的看这里的介绍nacos基础介绍，启动好之后，我们再来启动seata，bin目录下seata-server.bat
如果我们看到8091端口在监听，并且在nacos看到服务注册上去了，就表示我们seata启动成功了
到这里我们关于分布式事务的和seata的介绍就讲完了，其实关于分布式还有MQ实现可靠消息最终一致性，MQ主要解决了两个功能：本地事务与消息发送的原子性问题。事务参与方接收消息的可靠性，下一篇会讲解关于seata中AT、TCC、SAGA 和 XA 模式的介绍，感兴趣的小伙伴欢迎在下方留言，点赞过百，就是通宵也出下篇。
原文链接：https://mp.weixin.qq.com/s/Vuq_o1vbsbIfUfdqEBsUyg
