微服务中分布式事务的解决方案：seata【开发实践】_seata保证多个微服务的事务

一、事务简介

1.1 什么是事务（Transaction）

事务是一系列数据库操作的原子性集合，具备ACID四大特性。

其中事务有分为本地事务和分布式事务。本地事务只能保证单个设备上的ACID特性，无法实现分布式系统中的事务管理，所以提出了分布式服务。

1.2 ACID特性

• 原子性（Atomicity）：事务是一个不可分割的工作单位，意味着事务中的所有操作要么全部执行，要么全部不执行
• 一致性（Consistency）：事务的执行结果必须使数据库从一个一致性状态转换到另一个一致性状态
• 隔离性（Isolation）：事务的执行不应受到其他事务的干扰，每个事务都独立于其他并发事务执行（不允许多个并发的事务同时操作相同的数据）
• 持久性（Durability）：事务提交后，其对数据库的更改就应该是永久性的，即使系统发生故障也不会丢失

1.3 分布式事务的解决方案

常见的分布式事务的解决方案有：seata，消息队列，saga，XA

1.4 分布式事务的提交

大多数分布式事务采用的都是两段式（2PC）提交（3PC难以实现），包含Prepare阶段和Commit阶段，其中Commit阶段又分为正常提交事务和回滚事务两种情形。

二、分布式事务的两段式提交

2.1 Prepare阶段的流程

1. 询问：协调者向分布式事务的所有参与者发送事务请求，询问是否可执行事务操作，然后等待各个参与者的响应
2. 执行：各个参与者接收到协调者事务请求后，执行事务操作，并将Undo和Redo信息记录事务日志中（在回滚时要用）
3. 响应：参与者成功执行了事务并写入Undo和Redo信息，则向协调者返回YES响应，否则返回NO响应。当然，参与者也可能宕机，从而不会返回响应

2.2 Commit阶段：正常提交事务的流程

若协调者从所有参与者那里都及时收到了YES响应，则会在Commit阶段正常提交事务，此时的流程如下：

1. commit请求：协调者向所有参与者发送Commit请求
2. 事务提交：参与者收到Commit请求后，执行事务提交，提交完成后释放事务执行期占用的所有资源
3. 反馈结果：参与者执行事务提交后向协调者发送Ack响应
4. 完成事务：协调者接收到所有参与者的Ack响应后，完成事务提交

2.3 Commit阶段：回滚事务的流程

若协调者没有从所有参与者那里都及时收到YES响应，如接收到了NO响应或没有及时收到某个参与者响应，则会在Commit阶段回滚事务，此时的流程如下：

1. rollback请求：协调者向所有参与者发送Rallback请求
2. 事务回滚：参与者收到Rallback请求后，使用Undo日志执行事务回滚，完成后释放事务执行期占用的所有资源
3. 返回结果：参与者执行事务回滚后向协调者发送Ack响应
4. 的回滚事务：接收到所有参与者的Ack响应后，完成事务回滚

2.4 两阶段提交的问题

• 同步阻塞：协调者要等待所有参与者的响应（直到超时），在此之间，已经响应的参与者需要阻塞等待
• 单点：在2PC中，一切请求都来自协调者，协调者宕机将导致事务超时回滚。如果协调者也是分布式，使用选主方式提供服务，那么在一个协调者挂掉后，可以选取另一个协调者继续后续的服务，可以解决单点问题。但是，新协调者无法知道上一个事务的全部状态信息（例如已等待Prepare响应的时长等），所以也无法顺利处理上一个事务
• 数据不一致：Commit阶段，由于网络问题或宕机导致部分参与者没有收到Commit/Rallback请求，而收到了请求的参与者则会正常收到执行了Commit/Rallback操作。这将导致这些参与者之间的数据就不一致
• 环境可靠性依赖：环境问题，如网络中断，会导致超时回滚

三、分布式事务相关的定义和理论

3.1 CAP定理

分布式系统无法同时满足以下三个指标：

• 一致性：用户访问分布式系统中的任意节点，得到的数据是一致的
• 可用性：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝
• 分区容错：因为网络故障或其它原因会导致分布式系统中的部分节点与其它节点失去连接，形成独立的分区。集群中出现独立分区时仍能对外提供服务的能力就是分区容错能力

3.2 BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

• Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态
• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致

3.3 在高可用性和强一致性之间取舍的两个模式

分布式事务最大的问题是各个子事务的一致性问题，借鉴CAP定理和BASE理论，可以采用如下两个模式（方案）：

• AP模式：各子事务分别执行和提交，允许在中间过程出现不一致状态，采用弥补措施实现最终一致即可（优先高可用性）
• CP模式：各子事务执行后互相等待，在同时提交或同时回滚，以实现强一致性。代价是在事务的等待过程中处于弱可用状态（优先强一致性）

四、推荐的分布式事务解决方案：seata

4.1 seata中的三个角色（了解）

• TC (Transaction Coordinator)：事务协调者，维护全局和分支事务的状态，协调全局事务提交或回滚
• TM (Transaction Manager)：事务管理器，定义全局事务的范围，开始、提交或回滚全局事务
• RM (Resource Manager) ：资源管理器，管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚

TC为单独部署的服务端，TM和RM为嵌入到应用中的客户端

4.2 seata中分布式事务的生命周期（了解）

1. TM请求TC开启一个全局事务。TC会生成一个XID作为该全局事务的编号。XID会在微服务的调用链路中传播，保证将多个微服务的子事务关联在一起
2. RM请求TC将本地事务注册为全局事务的分支事务，通过全局事务的XID进行关联
3. TM请求TC告诉XID对应的全局事务是进行提交还是回滚
4. TC驱动RM们将XID对应的自己的本地事务进行提交还是回滚

4.3 Seata中为分布式事务提供的四种模式

• XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
• TCC模式：最终一致的分阶段事务模式，有业务侵入
• AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
• SAGA模式：长事务模式，有业务侵入

4.4 使用Seata的分布式事务

1. 引入依赖
2. 配置Seata（包括分布式事务的模式）
3. 使用（采用无业务侵入的模式，在方法上使用@GlobalTransactional来开启分布式事务）

4.5 @GlobalTransactional注解的三个属性

• name：指定事务名，相同事务名的事务同属一个事务，会触发事务管理
• timeoutMills：指定事务的超时时间
• rollbackFor：指定触发事务回滚的异常

4.6 使用了@GlobalTransactional后还有必要使用@Transactional吗

（看到某方法上同时使用了这两个注解，就提出了这个问题。以下是来自通义千问的回答）
在某些特定情况下，虽然开启了全局事务，但在具体的服务或DAO层方法中，仍可能需要对局部逻辑有更细粒度的事务控制要求。这种情况下，可以在全局事务内部的方法上适当使用@Transactional，但这不是必须的，而且要根据具体的业务逻辑和事务边界来决定。在实践中，应尽量避免不必要的重叠，确保事务管理的清晰性和简洁性。

五、参考博客推荐

【微服务】（十六）—— 分布式事务Seata
分布式事务：seata
Seata官网