博客

一 分布式事务简介

1，基本概念

我们都知道 Seata是一个分布式事务的解决方案，今天我们就来带大家了解一下什么是分布式事务，首先我们先来了解一下基础的知识，事务是什么？

事务是由一系列数据库操作组成的逻辑过程，可以是一个SQL查询，也可以是一组SQL查询。具备四个特性，也就是ACID。

• A(Atomic)：原子性，构成事务的所有操作，要么全部执行成功，要么全部执行失败，不会出现部分成功或者部分失败的情况。
• C(Consistency)： 一致性，在事务执行前后，数据库的一致性约束没有被破坏，比如，小勇去银行取100块钱，取之前是600，取之后应该是400，取之前和取之后的数据为正确数值为一致性，如果取出100，而银行里面的钱没有减少，要么小勇要笑醒了，这个就没有达到一致性的要求。
• I(Isolation):隔离性，数据库中的事务一般都是并发的，隔离性是只在并发的两个事务执行过程互不干扰，一个事务在执行过程中不能看到其他事务运行过程的中间状态，通过配置事务隔离级别可以避免脏读，重复读等问题。
• D(Durability)：持久性，当事务完成之后，事务对数据的更改会被持久化到数据库，且不会回滚

事务分为：本地事务和分布式事务。

2，本地事务

在计算机系统中，比较多的是通过关系型数据库来控制事务，这是利用数据库本身的事务特性进行实现的，因为应用主要靠关系型数据库来维持事务，加上数据库和应用都在同一个服务器，所以基于关系型数据的事务又被称为本地事务。例如我们常见的mysql事务就是本地事务。

3，分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理者分别位于不同的分布式系统的不同节点之上，且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败，分布式事务就是为了保证在不同服务器上数据库数据的一致性。

Seata 的设计思路是将多个服务器的本地事务组成一个全局事务，下面若干个本地事务，都能满足ACID，最好形成一个整的分布式事务，操作分布式事务就像是操作本地事务一样。

分布式系统会把一个应用拆分为多个可独立部署的服务，服务于服务之间通常需要远程协作才能完成事务的操作，这种分布式系统环境下由于不同的服务之间通过网络远程协作完成的事务被称为分布式事务，例如供应链系统中，订单创建（生成订单、扣减库存、履约通知发货）等。



在上图中我们可以看出，只要涉及到操作多个数据源，就会产生事务的问题，我们在实际开发中应该要避免这这个你问题的出现，但是虽然系统的拓展，应用和应用之间必然会产生应用之间事务的分离，当微服务架构中，主要有MQ和Seata，在了解他们之前，我们先来了解一下分布式事务是怎样组成，以及如何实现的。

二 分布式事务实现依据

分布式事务指的是事务的参与者，支持事务的服务器，资源服务器分别位于分布式系统的不同节点之上，通常一个分布式事物中会涉及到对多个数据源或业务系统的操作。

随着互联网的发展，从之前的单一项目逐渐向分布式服务做转换，现如今微服务在各个公司已经普遍存在，而当时的本地事务已经无法满足分布式应用的要求，因此分布式服务之间事务的协调就产生了问题，如果做到多个服务之间事务的操作，能够像本地事务一样遵循ACID原则，成为一个难题，但是在大牛们不断的探索下，终于找到了分布式事务存在两大理论依据： CAP定律和BASE理论

1，CAP定律

CAP定律由一致性（C）、可用性（A）、分区容错性（P）组成，在分布式系统中，不可能同时满足Consistency(一致性)/Availability(可用性)/Partition tolerance(分区容错性)三个特性，最多只能同时满足其中两项。

1. 一致性（C）：在分布式系统中所有的数据备份，在同一时刻保持一致的特性，所有的应用节点访问的都是同一份最新的数据副本。
2. 可用性（A）: 当集群中一部分节点故障以后，集群整体能够响应客户端的读写请求，对数据更新具备高可用性。
3. 分区容错性（P）： 如果系统在规定时间限制内不能达成数据的一致性，就表示要发生分区的情况，当前操作需要在C和A之间做出选择，让系统能够在遇到网络故障等情况的时候，任然能够保证对外提供满足一致性或者可用性的服务。

在上图中我们可以看到，当我们用户去购物车里面点击下单结算的时候，首先会经过我们库存服务，判断库存是否足够，当库存满足，扣减库存以后，我们需要将数据同步到其他服务器上，这一步是为了保证数据的结果的一致性，这个时候如果网络产生波动了，我们的系统需要保证分区容错性，也就是我们必须容忍网络所带来的一些问题，此时想保证一致性，就需要舍弃可用性。

但是如果为了保证高可用性，那么在高并发的情况下，是无法保证在限定时间内给出响应，由于网络的不可靠，我们的订单服务可能无法拿到最新的数据，但是我们要给用户做出响应，那么也无法保证一致性，所以AP是无法保证强一致性的

如果既想要保证高可用又想要保证一致性，必须在网络良好的情况下才能实现，那么解决方法只有一个，那就是需要将库存、订单、履约放到一起，但是这个就上去了我们微服务的作用，也就不再是分布式系统了。

在分布式系统中，分区容错性是必须存在的，我们只能在一致性和可用性上取舍，在这种条件下就诞生了BASE理论

2，BASE理论

BASE由 基本可用 (Basically Available)、软状态 (Soft state)和 最终一致性 (Eventually consistent) 三个构建而成，是对CAP中一致性和可用性权衡的结果，来源于对互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，核心四系那个是及时无法做到强一致性，但是每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

1.基本可用

基本可用是指当分布式系统出现不可预知故障的时候，允许损失部分可用性，但是这里并不是说表示系统不可以用，主要体现为以下几点:

• 响应时间上的损失，在正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户响应的查询结果，但是由于出现故障，查询结果的响应时间增加了1-2秒。
• 系统功能上的损失，在正常情况下，一个电子商务网站上进行购物，消费者几乎能够顺利的完成每一单操作，但是在一些节日大促销购物高峰期的时候，由于网站上购买量的猛增，为了保证系统的稳定性，部分消费者可能会引导到一个临时降级处理的页面或者提示
  
  
  
  基本可用的意思是，对于我们的核心服务是可以使用的，其他的服务可以适当的降低响应时间，甚至是进行服务降级处理，在当前中，库存和订单肯定是核心服务，至于我们的发货系统在当时只要保证基本可用就行，它的同步可以慢一点或者延迟更高，等待流量高峰过去以后，在进行恢复。

2.软状态

软状态是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统不用节点的数据副本之间进行数据同步的过程存在延时。



软状态的意思是说，当我们大量下单的时候，扣减库存时，流量激增，这个时候如果大量访问到库存或者订单中，可能会将系统弄垮，这个过程中我们可以允许数据的同步存在延迟，不影响整体系统的使用。

3.最终一致性

最终一致性强调的是所有数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态，因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不是需要实时保证系统的强一致性。



经过流量高峰期以后，经过一段时间的同步，从中间状态最后变成数据最终一致性，保证各个服务数据的一致性。

3，二阶段提交(2PC)

2PC即两阶段提交协议，是将整个事务流程分为两个阶段，P是指准备阶段，C是指提交阶段。

• 
  准备阶段
  
  (Prepare phase)：事务管理器给每个参与者发送 Prepare消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo日志，此时事务没有提交。

undo日志是记录修改前的数据，用于数据库回滚

Redo日志是记录修改后的数据，用于提交事务写入数据文件

• 提交阶段(commit phase)：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送(Rollback) 消息，如果收到参与者都成功，发送(Commit) 参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的资源。

成功提交：

事务管理器向所有参与者发送事务内容，询问是否准备好了，等待参与者的响应，各个参与者事务节点执行事务操作，并将 Undo和Redo信息记入事务日志中。如果参与者成功执行事务操作，反馈事务管理器YES操作，表示事务可以执行，假如协调者从所有的参与者或得反馈都是Yes响应，那么就会执行事务提交。




失败：

假如任何一个参与者向事务管理器反馈了No指令，或者等待超时之后，事务管理器无法接收到所有参与者的反馈响应，那么中断事务，发送回滚请求，事务管理器向所有参与者节点发送 RollBack请求，参与者接收到 RollBack请求后，会利用在阶段一记录的Undo信息执行事务的回滚操作，在完成回滚之后释放事务执行期间占用的资源，参与者在完成事务回滚之后，向协调者发送ACK消息，事务管理器在接受到所有参与者反馈的ACK消息之后，完成事务中断。

3,三阶段提交(3PC)

3PC 主要是为了解决两阶段提交协议的单点故障问题和缩小参与者阻塞范围。 是二阶段提交（2PC）的改进版本，引入参与节点的超时机制之外，3PC把2PC的准备阶段分成事务询问（该阶段不会阻塞）和事务预提交,则三个阶段分别为 CanCommit、PreCommit、DoCommit.

1.CanCommit询问状态

CanCommit阶段 协调者(Coordinator)会向参与者(Participant) 发送CanCommit消息，询问是否可以执行操作，参与者收到消息后，表示能够执行，会返回给协调者能够执行的(yes)命令。



如果参与者不能执行，会返回No命令,释放资源，结束事务。

2.PreCommit预提交

PreCommit阶段如果协调者收到参与者返回的状态值为YES，那么就证明它们都有能力去执行这个操作，那么协调者就会向所有参与者 发送 PreCommit消息，协调者收到 PreCommit消息后，回去执行本地事务，如果执行成功会将本地事务保存到 undo和redo后，再返回给协调者YES指令，如果执行本地事务失败，返回协调者No,只要协调者收到一个执行失败，给所有参与者发送中断事务消息，参与者收到消息后，对事务进行回滚操作。

在这个阶段参与者和协调者都引入了超时机制，如果参与者没有收到，协调者的消息，或者协调者没有收到参与者返回的预执行结果状态，在等待超时之后，事务会中断，避免了事务的阻塞。

协调者向参与者发送PreCommit，如果参与者执行成功，返回yes



如果参与者执行失败，只有有一个返回No到协调者，协调者会向参与者发送中断事务的消息，参与者回滚事务。

3.DoCommit提交

协调者收到所有参与者返回的状态都是YES，这时协调者会向所有的参与者都发送 DoCommit，参与者收到 DoCommit后，会真正的提交事务，当事务提交成功后，返回协调者YES状态，表示我已经完成事务的提交了，协调者收到所有参与者都返回YES状态后，那么就完成了本次事务。

如果某个参与者返回No消息，协调者发送中断事务消息(abort)，给参与者们，参与者回滚事务



3PC是2PC的升级版，引入了超时机制，解决了单点故障引起的事务阻塞问题，但是3PC依然不能解决事务一致性的问题，因为在DoCommit阶段，如果由于网络或者超时等原则导致参与者收不到协调者发送过来的 中断事务消息(abort) ，过了这个时间后，参与者会提交事务，本来是应该进行回滚，提交事务后，会导致数据不一致的问题出现，2PC虽然在网络故障情况下存在强一致性被破坏的问题，但是故障恢复以后能保证最终一致性，3PC虽然有超时时间，解决了阻塞，提高了可用性，但是牺牲了一致性，如果针对网络波动问题导致数据问题这一点上，2PC是优于3PC的