分布式事务方案 - SAGA模式

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

　　内容包括：

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

　　补充：

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

　　1. 分布式事务问题描述

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

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

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

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

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

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

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

　　ChoreographyOrchestrator

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

　　2. SAGA - Choreography 策略

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

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

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

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

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

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

　　重点看异常处理流程：

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

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

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

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

　　3. SAGA - Orchestration

　　Orchestration 是乐队编排的意思。

　　对应到分布式事务，各个服务就是乐队中的各个演奏者，还需要一个【总指挥】，所以在 SAGA - Orchestration 策略中会单独创建一个此角色。

　　

　　如上图，正常处理流程：

　　订单服务写自己的业务数据订单服务向总指挥报告自己完成了总指挥向库存服务发送执行指令库存服务写数据库存服务报告自己完成了总指挥向订单服务发送指令订单服务更新订单状态总指挥向物流服务发送指令

　　......

　　后面的就不细说，都是一个思路。

　　异常处理的思路也是一样的，还是假设物流服务异常了，那么它会向总指挥报告，总指挥就会向订单服务、库存服务发送回滚的指令。

　　所以 Orchestration 策略的重点在于总指挥，需要为其定义指挥手册，以便总指挥在不同的时刻向相应的服务发送对应的指令。

　　这个总指挥实际上是通过【状态机】来实现的。

　　此策略好处是服务之间没有关联了，整体结构清晰。坏处是都了一个总指挥的角色，增加了复杂度。

　　4. 小结

　　Choreography 策略是通过事件机制实现的，每个服务都监听自己所关心的事件，每个服务执行后会发送相应的事件，监听此事件的服务执行相应的处理逻辑。

　　Orchestration 是通过状态机来实现的整体控制，定义整体的处理流程，不同状态下需要触发的动作。