标签：事务 服务 SAGA 订单 事件 分布式

本文目的是讲清楚 SAGA 这种分布式事务解决方案的实现思路，不包括具体实现代码，具体实现推荐使用阿里的Seata 框架。

内容包括：

• 分布式事务问题描述
• SAGA - Choreography 策略
• SAGA - Orchestration 策略

补充：

常用的分布式事务解决方案还包括TCC、 可靠消息模式 。

1. 分布式事务问题描述

 

比如说电商系统中，用户下单了，后端需要调用：

• 订单服务，创建订单
• 库存服务，改商品的库存
• 物流服务，创建物流单，准备发货

在分布式的微服务架构中，每个服务都会有自己独立的数据库，那么，这个下单的动作就涉及到了向多个数据库中写入数据。

因为不是在同一个数据库中，所以就不能依赖数据库的事务机制了，但是在业务逻辑中，这几个写库操作就应该是一个事务。

比如订单服务、库存服务中都写入成功了，但物流系统出现异常了，那么订单服务、库存服务就应该进行回滚，来保证整体数据的一致性。

如何在跨数据库的情况下实现事务呢？这就是分布式事务问题。

SAGA 就是一种老牌的分布式事务解决方案，已经有20来年了，其实现方式主要有两种：

• Choreography
• Orchestrator

下面介绍一下各自的实现思路。

2. SAGA - Choreography 策略

 

Choreography 是编舞的意思，就是把舞者之间的动作配合都编排好。

对应到分布式事务，就可以把各个服务理解为舞者，SAGA 的 Choreography 策略就是要定义好先执行哪个服务，根据执行结果再触发哪些服务的执行。

 

如上图，整体分布式事务处理流程为：

1. 订单服务写自己的业务数据，并在数据库中 记录 一下订单的整体 状态 ，比如记为 "已下单"。
2. 订单服务发布【订单创建成功】事件，库存服务会监听此事件。
3. 库存服务收到事件通知后，写自己的业务数据，然后发布【库存修改成功】事件。
4. 订单服务会监听此事件，收到事件通知后，修改订单状态，比如 "待发货"。
5. 物流服务也会监听此事件，收到事件通知后，写自己的业务数据，然后发布【物流处理成功】。
6. 订单服务会监听此事件，收到通知后，修改订单状态，改为 "已发货"。

这样，通过事件机制，各个服务之间完成协同配合，实现了分布式事务。

下面看异常情况的处理，比如物流服务异常了，如下图。

 

重点看异常处理流程：

1. 物流服务会发布事件【物流处理异常】。
2. 订单服务、库存服务都监听此事件，所以会收到物流异常的通知。图中（8）、（9）。
3. 订单服务执行自己的回滚逻辑。图中（10）。
4. 库存服务执行自己的回滚逻辑。图中（11）。

这样就实现了分布式事务的异常处理。

SAGA Choreography 策略是通过【事件机制】实现的，各个服务都定义好正常、异常的处理方法，然后监听目标事件，根据不同的事件来调用不同的处理方法。

此策略好处是实现简单，坏处是整体事件逻辑会比较复杂，比如有10个服务参与其中，那么整体事件订阅关系就会很凌乱。

标签：事务,服务,SAGA,订单,事件,分布式
From： https://www.cnblogs.com/muxilaoshi/p/17004776.html