Seata

Seata

1.什么是Seata

Seata 是一个开源的分布式事务解决方案，旨在为微服务架构提供高性能和简单易用的事务管理。随着微服务架构的普及，服务之间的调用变得越来越复杂，传统的单体应用事务管理方式已无法满足需求。Seata 为微服务之间提供了一种有效的分布式事务管理机制。
举例说明：
假设有一个简单的电商应用，包含订单服务、库存服务和账户服务。当用户下单时，需要执行以下操作：
订单服务：创建一个新订单。
库存服务：减少商品库存。
账户服务：扣减用户账户余额。
在没有分布式事务管理的情况下，如果上述任一步骤失败，比如库存扣减成功但账户扣费失败，就会导致数据不一致的问题。

使用 Seata 管理这个分布式事务的过程如下：
1.开始事务：当用户下单操作开始时，Seata 会开始一个新的分布式事务。
2.执行业务操作：
订单服务创建订单，并向Seata注册这个分支事务。
库存服务扣减库存，并向Seata注册这个分支事务。
账户服务扣减余额，并向Seata注册这个分支事务。
3.提交/回滚事务：
如果所有服务都成功执行，Seata 会协调提交所有分支事务，确保数据的一致性。
如果任何一个服务报告失败，Seata 会协调回滚所有分支事务，确保系统回到事务开始前的状态。

2.为什么需要Seata

在传统的单体应用中，通常通过本地数据库事务来保证数据的一致性和完整性。然而，在分布式环境中，多个服务器可能进行跨数据库跨服务的操作，此时仅使用本地事务无法保证全局事务的一致性。这就需要引入分布式事务来协调多个服务之间的操作，保证分布式系统的数据一致性和可靠性。

本地事务智能针对单个数据库的主要原因是，事务的原子性和一致性是基于数据库连接的。在一个数据库连接上执行的多个操作可以通过本地事务来保证原子性和一致性，因为它们共享同一个数据库连接和事务上下文。当一个事务开始时，在事务范围内的所有操作都使用相同的数据库连接，这确保了这些操作可以在同一个数据库事务中进行。在事务执行期间，如果任何一个操作失败，可以回滚整个事务，保证数据的一致性，也可以提交整个事务，完成一系列操作的原子性。
然而，当涉及到多个数据库或服务时，每个数据库或服务都有独立的连接和事务上下文。本地事务无法保证多个数据库连接之间的数据一致性和原子性，因为它们无法在全局范围内进行协调和控制。
因此，为了实现跨多个数据库或服务的事务一致性，需要引入分布式事务的概念，通过统一的事务管理中心来协调和管理多个服务之间的事务操作。分布式事务工具如Seata可以提供全局事务管理，确保多个服务的操作要么全部成功，要么全部回滚，以保证数据的一致性和可靠性。而分布式事务是通过将多个本地事务组合成一个全局事务，确保所有涉及的数据库或服务在一个事务中要么全部成功，要么全部回滚。分布式事务的实现需要一个统一的事务管理中心，用于协调和管理多个服务之间的事务操作。Seata就是一个分布式事务解决方案，可以帮助处理分布式环境中的事务一致性的问题。

3.主要特点

1.分布式事务管理：Seata 管理分布式事务的完整生命周期，包括事务的开始、提交、和回滚。
2.高性能：通过优化事务日志存储和通信机制，Seata 能够确保在保证数据一致性的同时，最小化性能损失。
3.易于集成：Seata 提供了与多种微服务框架（如Spring Cloud、Dubbo）和数据库中间件的集成能力。
4.AT、TCC、Saga、XA事务模式：Seata 支持多种事务模式，包括但不限于自动补偿事务（AT）、两阶段提交（XA）、补偿事务（TCC）和长事务（Saga），以满足不同场景下的分布式事务需求。

4.Seata组成

Transaction Coordinator [TC]：事务协调器，负责维护全局事务的状态，以及协调分支事务的提交和回滚。
Transaction Manager[TM]: 事务管理器，定义全局事务的范围，负责开始和结束全局事务。
Resource Manager [RM]： 资源管理器，负责管理分支事务的资源，与 TC 通信注册分支事务，并报告分支事务的状态。

工作流程
假设一个电商系统中，用户下单操作需要调用“订单服务”创建订单和“库存服务”扣减库存两个操作，这两个操作需要在一个分布式事务中完成。
1.TM 开始一个新的分布式事务，并向 TC 注册这个事务获取全局事务ID。
2.订单服务（RM）和库存服务（RM）分别执行它们的业务逻辑，比如创建订单和扣减库存，并将它们的操作作为分布式事务的分支注册到 TC。
4.一旦所有 RM 完成它们的操作，TM 根据业务逻辑的执行结果决定是提交还是回滚整个分布式事务。
5.TM 通知 TC 进行提交或回滚，TC 再指导所有的 RM 根据 TM 的决定来提交或回滚各自的局部事务。

我来尝试用一个更简单的比喻来说明TC（Transaction Coordinator，事务协调器）、TM（Transaction Manager，事务管理器）和RM（Resource Manager，资源管理器）在Seata中的关系和工作方式。

5.举例说明

比喻说明：
假设你是一位餐厅的大厨（TM），负责管理厨房里制作一道菜所需要的各个步骤。这道菜需要用到炉子（RM1）来煮汤，同时还需要烤箱（RM2）来烤面包。

1.开始制作菜品：
你决定开始制作这道菜，因此你告诉餐厅经理（TC），你要开始一个“制作过程”（全局事务）。
2.执行步骤：
你首先去炉子那里（RM1），告诉炉子，你要用它来煮汤。炉子记录下来你要做的事情，并告诉餐厅经理（TC）它现在正在为这道菜煮汤。
然后你去烤箱那里（RM2），告诉烤箱，你接下来要用它来烤面包。烤箱也记录下来，并告诉餐厅经理（TC）它正在烤面包。

3.完成制作：
煮汤和烤面包这两个步骤都成功完成后，炉子和烤箱分别告诉餐厅经理（TC），他们各自的任务都完成了。

4.提交：
餐厅经理（TC）得知煮汤和烤面包都成功完成，便告诉你这个好消息。作为大厨的你（TM）决定，既然所有步骤都完成了，这道菜也就成功制作完成，可以出餐了。

对应到Seata：
TC（餐厅经理）：负责监督整个制作过程（全局事务），确保所有步骤（分支事务）都能成功完成，如果有任何一个步骤失败，它会告知所有相关的步骤撤销操作，保证不会有半成品出现。
TM（大厨）：决定开始和结束一个全局事务，即从制作这道菜的开始到最终出餐的整个过程。
RM（炉子和烤箱）：负责执行具体的步骤（分支事务），比如炉子负责煮汤，烤箱负责烤面包，它们各自向TC报告自己的任务执行情况。

6.Seata模式介绍

1.XA模式（两阶段提交）：
简介：XA 模式通过两个阶段来保证分布式事务的一致性。
第一阶段（准备阶段）：在这一阶段，全局事务协调器（TC）向所有参与的服务（资源管理器，RM）发送准备请求。每个参与者（RM）执行本地事务的准备操作，但不会提交事务。然后，它们将准备结果（成功或失败）返回给协调器。如果所有参与者都成功准备，准备阶段完成，准备进入提交阶段。如果任何一个参与者报告准备失败，协调器决定中止事务，并准备进入回滚阶段。
第二阶段（提交/回滚阶段）：如果第一阶段所有参与者都成功准备，协调器发送提交请求给所有参与者，指示它们提交各自的本地事务。
如果第一阶段有任何一个参与者准备失败，协调器发送回滚请求给所有参与者，指示它们回滚各自的本地事务。

假设一个电商应用，用户下单操作涉及到两个独立的系统：订单系统和库存系统。订单系统负责记录用户的订单信息，库存系统负责扣减商品库存。这两个操作必须要么同时成功，要么同时失败，以保证数据的一致性。

1.开始全局事务：TM 开始一个全局事务，并向TC注册这个事务。
2.阶段一：准备（Prepare）：
TM 通知所有参与的RM准备执行事务。这里的RM（例如，订单系统的数据库和库存系统的数据库）开始执行各自的操作，如插入订单记录和扣减库存，但不提交事务，而是准备好提交并等待TC的最终指令。
RM执行完各自的操作后，将准备结果返回给TC。TC收集所有RM的准备结果。
3.阶段二：提交或回滚（Commit/Rollback）：
如果所有RM都成功准备，TC指示所有RM提交（commit）各自的事务，完成操作。
如果任何RM准备失败，TC指示所有RM回滚（rollback）各自的事务，撤销操作。

也就是说，TC决定提交或者回滚，而TM是开始和结束全局事务，且提交/回滚事务不等于开始/结束事务

XA模式为什么要将事务设置为串行化？
在分布式事务中，特别是使用XA模式时，将事务隔离级别设置为串行化（Serializable）可以提供最高级别的事务隔离。这意味着每个事务都是完全独立地执行，仿佛是按顺序一个接一个执行，从而避免了并发事务可能引起的数据不一致问题，如脏读、不可重复读和幻读。
因此，为了使用XA模式的分布式事务，需要在事务上设置为串行化，以保证事务的正确执行和一致性。

2.AT模式（自动补偿事务）：
是XA的升级版
简介：AT 模式通过记录数据的前后状态来实现事务。如果事务需要回滚，它就通过这些记录来自动把数据恢复到事务开始前的状态。
例子：想象你在一个电子游戏中走到了一个检查点，游戏自动保存了你的状态（健康值、子弹数量等）。如果你在接下来的游戏中失败了，游戏就会自动把你带回到检查点时的状态，就像什么都没发生一样。
假设你在一个在线购物应用中，用户下单操作需要更新两个微服务的数据：订单服务（创建订单）和库存服务（减少库存）。
开始事务：用户点击下单，开始一个分布式事务。此时，事务管理器（TM）记录这个事务的开始。
执行操作：
订单服务：创建一个新的订单。在修改数据前后，系统自动记录下订单数据的前后状态（比如没有订单到有一个新订单的状态）。
库存服务：减少商品的库存数量。同样，在修改库存数据前后，系统记录下库存数据的前后状态（比如库存从10减少到9）。
对于每个服务的操作，系统都会在数据库中生成一个特殊的日志（称为undo log），记录如何从修改后的状态回滚到原始状态。
尝试提交事务：如果订单创建和库存减少都成功执行，系统尝试提交整个分布式事务。
自动补偿（回滚）：
如果在尝试提交事务的过程中，发现任何问题（比如库存服务执行失败），整个事务需要回滚。
此时，系统利用之前记录的undo log，自动将订单服务和库存服务的数据恢复到事务开始前的状态，就像这个事务从未发生过一样。

关键点
自动记录状态：系统自动记录每次数据修改的前后状态，无需开发者手动管理。
自动补偿（回滚）：如果事务失败，系统可以自动回滚所有更改，保证数据一致性。
无锁实现：AT模式不依赖于分布式锁，提高了系统的并发能力和性能。
3.TCC模式（Try-Confirm-Cancel）：
简介：TCC 分为三个步骤：尝试（Try）、确认（Confirm）和取消（Cancel）。首先尝试执行事务，预留必要资源；然后根据执行结果确认提交或取消回滚，释放或恢复资源。
Try： 预留必要的业务资源。这一步不执行实际的业务逻辑，只是检查数据的有效性和预留资源，确保Confirm步骤能够顺利执行。
Confirm： 如果所有服务的Try操作都成功，那么执行Confirm操作，正式完成业务逻辑。这一步会真正地修改数据，释放在Try阶段预留的资源。
Cancel： 如果任何一个服务的Try操作失败，或者某种原因需要回滚事务，那么执行Cancel操作。Cancel步骤负责释放或回滚在Try阶段预留的资源，撤销之前的操作，确保系统回到事务开始前的状态。
例子：想象你在网上订餐。首先（Try），餐馆确认有足够的食材准备你的菜（预留资源）。如果一切就绪，你完成支付，餐馆就开始做饭（Confirm）；如果你取消订单或支付失败，餐馆就停止准备，释放那些食材（Cancel）。

TCC例子：在线商城下单
Try阶段：
订单服务：验证订单详情，如商品信息、用户信息等，并预留一个订单记录（但此时订单状态为未确认）。
库存服务：检查所购买商品的库存量是否足够，并预留相应数量的库存（减少可售库存数量，但不是最终扣减）。

Confirm阶段（只有当所有Try操作都成功）：
订单服务：将预留的订单记录状态更新为已确认。
库存服务：确认扣减库存，更新库存信息。

Cancel阶段（如果Try阶段任一操作失败）：
订单服务：取消预留的订单记录。
库存服务：恢复预留的库存数量。

TCC（Try-Confirm-Cancel）模式被称为显式补偿是因为它要求开发者针对每个分布式事务操作明确定义补偿逻辑（Cancel操作）。这种补偿逻辑需要手动编写，以确保在事务执行过程中如果出现任何问题，可以通过执行这些补偿操作来撤销已完成的工作，从而保证数据的一致性和系统的稳定性。
显式补偿的特点
明确性：在TCC模式中，每个事务操作分为三个明确的阶段：尝试（Try）、确认（Confirm）和取消（Cancel）。其中，取消阶段需要开发者为每个事务操作编写明确的补偿逻辑。
手动编写：补偿逻辑（Cancel逻辑）需要根据业务需求手动编写。这意味着开发者必须事先考虑事务操作可能失败的场景，并为这些场景准备相应的补偿操作。
业务逻辑的一部分：补偿逻辑成为整个业务逻辑的一部分。开发者需要在业务代码中显式地处理事务的每个阶段，包括成功时如何确认（Confirm）和失败时如何撤销（Cancel）。

为什么是显式的
与其他一些分布式事务模式相比，如基于日志的补偿（如AT模式）或Saga模式中的隐式补偿，TCC要求开发者在编码时就明确地处理事务的成功和失败路径。这种需要手动定义和管理补偿操作的特性，使得补偿在TCC模式中是显式的。

4.SAGA模式：
简介：Saga 通过一系列的局部事务来管理一个全局事务，每个局部事务都有对应的补偿事务。如果某个局部事务失败，会执行之前成功的局部事务的补偿操作来回滚事务。
例子：想象你在规划一次长途旅行，包括订机票、订酒店和租车。每完成一个步骤就是一个局部事务。如果租车失败了，你需要取消酒店和机票的预订。每个步骤的取消就是它的补偿事务。
为什么说取消机票和酒店就是补偿事务呢？
补偿事务的概念
补偿事务是Saga模式中的一个核心概念，用于撤销之前已成功执行的事务步骤。在分布式系统中，由于多个服务之间的操作通常是松耦合的，且每个服务可能独立管理自己的数据库，因此不能简单地依赖数据库事务来回滚整个业务操作。Saga通过为每个业务操作定义相应的补偿操作来实现业务流程的回滚。
为什么是补偿
非原子性：在分布式系统中，业务流程通常跨越多个服务，每个服务的操作不能简单地通过传统的ACID事务原子性来控制。一旦某个服务的操作失败，需要一种机制来确保之前成功的操作不会对系统造成不一致的影响。
显式撤销：补偿事务显式地撤销或回滚之前的操作。在旅行预订的例子中，如果租车预订失败，需要显式地取消航班和酒店的预订，这些取消操作作为补偿事务执行，以恢复到业务操作开始前的状态。
业务逻辑的一部分：补偿事务通常涉及具体的业务逻辑，比如如何取消航班预订、退款处理等。这些逻辑需要开发者根据业务需求明确定义
在Saga模式中，每个步骤（本地事务）都需要定义对应的补偿事务。这些补偿事务在业务流程中的某个步骤失败时被触发，按照一定的顺序（通常是反向的顺序）执行，以撤销之前的操作。补偿事务确保了即使在复杂的分布式环境中，业务流程也能在遇到失败时保持一致性和完整性。
因此，将取消航班和酒店预订称为补偿事务是因为它们直接关联到撤销之前成功的业务操作，以应对失败情况，保证整个业务流程的一致性和稳定性。
也就是说，你可以认为所谓的补偿，就是为了让业务主流程不出问题

XA和AT已经能满足百分之99.99的场景了，如果在你开发生涯中有某种场景比较特殊，可以用TCC或SAGA