我们都知道这是一个分布式事务解决方案。今天，我们将带您了解什么是分布式事务。首先，我们将学习基本知识-事务。首先，我们将了解交易的概念。

事务的四部分-acid

A： 原子性：构成事务的所有操作要么成功执行，要么完全失败。不会发生部分成功或部分失败。

【资料图】

事务分为两部分：本地事务和分布式事务

本地交易：

在计算机系统中，大多数事务都是通过关系数据库控制的，关系数据库是利用数据库本身的事务特性来实现的。由于应用程序主要依赖关系数据库来维护事务，并且数据库和应用程序位于同一服务器上，因此基于关系数据的事务也称为本地事务。

分布式事务：

分布式事务是指事务的参与者、支持事务的服务器、资源服务器和事务管理器，它们位于不同分布式系统的不同节点上，属于不同的应用。分布式事务需要确保所有这些操作成功或失败。分布式事务是为了确保不同服务器上数据库数据的一致性。

Seata的设计思想是将多个服务器的本地事务合并为一个全局事务。以下本地事务可能会遇到acid。最好形成一个完整的分布式事务。操作分布式事务就像操作本地事务一样。

分布式系统将应用程序拆分为多个可独立部署的服务。服务通常需要远程协作来完成事务操作。在这种分布式系统环境中，通过网络在不同服务之间远程协作完成的事务称为分布式事务，例如供应链系统中的订单创建

在上图中，我们可以看到，只要涉及多个数据源的操作，就会发生事务。我们应该在实际发展中避免这个问题。然而，尽管系统不断扩展，但应用程序之间的事务将不可避免地分离。在微服务架构中，主要使用MQ和Seata。在了解它们之前，让我们先了解分布式事务是如何组成的，以及如何实现它。

什么是分布式事务

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

随着互联网的发展，微服务已经从单一的项目逐渐转变为分布式服务。如今，微服务在各个公司都很普遍。当时，本地事务已不能满足分布式应用程序的要求。因此，分布式服务之间的事务协调产生了问题。如果操作多个服务之间的事务，那么像本地事务一样遵循acid原则将成为一个难题，然而，在Daniel的不断探索下，他们最终找到了分布式事务的两个理论基础：cap定律和base理论

Cap法则由一致性组成。在分布式系统中，不可能同时满足三个特性，但只能同时满足其中两个特性。

一致性：在分布式系统中，所有数据备份都是同时一致的。所有应用程序节点都访问相同的最新数据副本。

可用性：当集群中的一些节点出现故障时，整个集群可以响应客户端的读/写请求，并具有数据更新的高可用性。

分区容错：如果系统未能在指定的时间限制内实现数据一致性，则意味着将发生分区。当前操作需要在C和a之间进行选择，以便系统在网络故障时仍能提供一致性或可用性服务。

在上图中，我们可以看到，当我们的用户前往购物车并单击下单进行结算时，他们将首先通过我们的库存服务来确定库存是否充足。当满足库存并扣除库存时，我们需要将数据同步到其他服务器。这一步是为了确保数据结果的一致性。此时，如果网络出现波动，我们的系统需要保证分区容错，即必须容忍网络引起的一些问题。此时，如果我们想确保一致性，就需要放弃可用性。

然而，为了确保高可用性，在高并发的情况下，无法在有限的时间内保证响应。由于网络的不可靠性，我们的订单服务可能无法获取最新数据，但我们必须响应用户，因此无法保证一致性。因此，Ap不能保证强一致性

如果您想同时确保高可用性和一致性，那么只有在网络良好的情况下才能实现。只有一种解决方案，即您需要将库存、订单和性能放在一起。然而，这取决于我们的微服务的角色，它不再是一个分布式系统

在分布式系统中，必须存在分区容错。我们只能在一致性和可用性之间进行选择。在这种情况下，基础理论诞生了

基本可用性：基本可用性是指在分布式系统发生不可预测的故障时，允许丢失一些可用性。但是，这并不意味着系统不可用。主要体现在以下几点：

响应时间的损失。在正常情况下，在线搜索引擎需要在0.5秒内将查询结果返回给用户。但是，由于失败，查询结果的响应时间增加了1-2秒

系统功能的丧失。在正常情况下，消费者在电子商务网站上购物时，几乎可以顺利完成每个订单。但是，在一些节日的购物旺季，由于网站上的购买量急剧增加，为了保证系统的稳定性，一些消费者可能会导致页面或提示进行临时降级处理

基本可用意味着我们的核心服务可以使用。其他服务可以适当缩短响应时间，甚至降低服务的级别。目前，库存和订单无疑是核心服务。至于我们的运输系统，只需确保当时基本可用即可。它的同步速度可能较慢或更延迟。交通高峰过后，将恢复。

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

软状态意味着，当我们下大量订单并扣除库存时，流量激增。此时，如果我们访问大量库存或订单，系统可能会崩溃。在此过程中，我们可以允许延迟数据同步，而不会影响整个系统的使用。

最终一致性：最终一致性强调所有数据拷贝在经过一段时间的同步后最终可以达到一致状态。因此，最终一致性的实质是系统需要确保最终数据的一致性，而不是系统实时的强一致性。

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

2pc是一个两阶段提交协议，它将整个事务过程分为两个阶段。p表示准备阶段，C表示提交阶段。

例如，当我们去KCC买冰淇淋时，有一个活动。第二杯是半价，但只有你一个人。这时，一个小妹妹来了，正在考虑是否买冰淇淋。此时，你向她提出了AA，也就是说，只有当你和她同意购买时，你才能购买它。如果这两个人中有一个人不同意，你就不能买这个冰淇淋。

第一阶段：在准备阶段，老板要求你先付款。在你同意付款后，你可以要求这位女士付款。这位女士同意付款

第二阶段：付款在提交阶段完成，老板给了他们一顿饭，他们俩都吃冰淇淋

此示例构成一个事务。如果其中一个男人和女人拒绝付款，老板将不给他饭，并将退还他收取的钱。

整个事务流程由事务管理器和参与者组成。店主是交易经理，你和女孩是参与者。事务管理器对整个分布式事务进行决策。计算机中的关系数据支持两阶段提交协议：

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

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

提交阶段：如果事务管理器接收到来自参与者的执行失败或超时消息，它会根据事务管理器的指示直接发送给每个参与者执行提交或回滚操作，并释放事务处理过程中使用的资源。

已成功提交：

事务管理器将事务内容发送给所有参与者，询问其是否准备就绪，等待参与者的响应，每个参与者事务节点执行事务操作，并将信息记录在事务日志中。如果参与者成功执行了事务操作，事务管理器将以“是”操作响应，表示可以执行事务。如果协调器收到所有参与者的“是”响应，则将执行事务提交。

失败：

如果任何参与者将no指令反馈给事务管理器，或者事务管理器在等待超时后未能收到所有参与者的反馈响应，则事务管理器会中断事务并发送回滚请求。事务管理器向所有参与者节点发送请求。在收到请求后，参与者将使用阶段1中记录的撤销信息回滚事务，回滚完成后，释放事务执行期间占用的资源。事务回滚完成后，参与者向协调器发送ACK消息。事务管理器从所有参与者收到ACK消息后，完成事务中断。

3pc主要用于解决两阶段提交协议的单点故障，减少参与者的拥塞范围。它是两阶段提交的改进版本。3pc除了引入参与节点的超时机制外，还将2pc的准备阶段分为事务查询和事务预提交。这三个阶段是

阶段协调器发送一条消息，询问是否可以执行该操作。收到消息后，参与者表示可以执行该消息，并将返回协调器可以执行的命令

如果参与者无法执行，将返回no命令以释放资源并结束事务。

在该阶段中，如果协调器接收到参与者返回的状态值为“是”，则证明他们能够执行此操作。然后协调员将向所有参与者发送消息。收到消息后，协调器将返回执行本地事务。如果执行成功，协调器将本地事务保存到，然后将其返回给协调器yes指令。如果本地事务执行失败，将返回协调器no，只要协调器接收到执行失败，它就会向所有参与者发送中断事务消息。收到消息后，参与者回滚事务。

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

协调员将消息发送给参与者。如果参与者成功执行消息，则返回yes

如果参与者未能执行，则只有一个参与者向协调器返回no。协调器将向参与者发送消息以中断事务，参与者回滚事务。

当协调员收到所有参与者返回的状态为“是”时，协调员会将其发送给所有参与者。参与者收到交易后，他们将实际提交交易。事务提交成功后，将返回协调员的“是”状态，表示我已完成事务提交。协调员收到所有参与者返回到“是”状态后，事务将完成。

如果参与者返回no消息，协调器将向参与者发送中断事务消息，参与者回滚事务

Seata是一个开源分布式事务解决方案，致力于提供高性能和易于使用的分布式事务服务。Seata将为用户提供at、TCC、Saga和XA事务模式，为用户创建一站式分布式解决方案。

在微服务系统中，一般业务将被划分为独立的模块。从官方提供的结构图中可以看出，目前主要分为三个模块

库存服务：增加或减少商品库存信息

订单服务：根据用户指定的商品生成订单

账户服务：从用户账户中扣除余额、加分、维护地址信息等

在当前的体系结构中，用户在选择所需商品并下订单后需要三个服务来完成操作。每个服务都有一个独立的本地事务，以确保当前服务数据的强一致性，但无法保证由三个服务组成的全局事务一致性。西塔是来解决这个问题的。

在学习Seata之前，让我们先了解Seata的一些关键概念：

维护全局和分支事务的状态，并驱动全局事务提交或回滚

阶段1：在同一个本地事务中提交业务数据和回滚日志记录，并释放本地锁和连接资源。

阶段2：异步提交并快速完成。回滚通过一个阶段的回滚日志执行反向补偿。

在第一阶段提交本地事务之前，需要确保首先获得全局锁。无法获取全局锁，无法提交本地事务。

获取全局锁的尝试被限制在一定范围内。如果超出范围，将放弃该范围，并回滚本地事务以释放本地锁。

根据数据库本地事务隔离级别read COMMITED或更高级别，Seata的默认全局隔离级别为read UNCOMMITED

如果应用程序处于特定场景中，则必须提交全局读取。目前，Seata的方法是通过select for UpDATE语句的代理。

Seata执行流程分析：

每个RM使用链接的数据路径进行使用。使用数据源和数据代理的目的是在第一阶段提交本地事务中的撤消和业务数据。这节省了只要有业务操作，就必须有dudo日志，

在第一阶段，undo存储数据修改前后修改的值，以准备事务回滚。第一阶段完成后，分支事务已提交，锁资源已释放。

TM启动全局事务，将XID全局事务ID放在事务上下文中，通过外呼将XID传递给下游服务器，每个分支事务将自己的分支ID与XID关联，

在全球交易提交的第二阶段，TC将通知每个分行参与者提交分行交易。在第一阶段，已提交分行交易记录。这里，每个参与者只需要删除undo，就可以异步执行。

如果某个分支事务异常，在全局事务回滚的第二阶段，TC会通知每个分支参与者回滚该分支事务，通过XID和分支ID找到相应的回滚日志，并通过回滚日志生成的反向SQL执行完成分支事务到前一状态的回滚。

解压缩后查找conf目录

在启动Seata之前，我们应该先启动Nacos。事实上，这很简单。我们只需要下载Nacos并启动它。我不知道Nacos是怎么运作的。请参见此处的Nacos基本介绍。启动后，我们可以在bin目录下启动Seata

如果我们看到端口8091正在侦听，并且服务注册在Nacos上，这意味着我们已经成功启动了Seata

到目前为止，我们已经完成了分布式事务和Seata的介绍。事实上，还有MQ来实现可靠消息的最终一致性。MQ主要解决两个功能：本地事务的原子性和消息发送。交易参与者收到的消息的可靠性。下一篇文章将解释Seata中的模式。欢迎有兴趣的合作伙伴在下面留言。如果你一百次喜欢它，下一篇文章将在一夜之间发表。

我是一个小农。恐怕真相是无限的。还有更多的快乐。来吧