事务探索

1 事务概述

事务具有 4 个特性：这四个特性通常称为 ACID 特性。

网上对四个词的解析文章包括后续扩展的比如分布式事务的二阶段提交，三阶段提交，TCC等方式都有详细的说明，这里就不重复解释了（写不完，根本写不完）！

本篇文章着重给大家呈现出不同的方案能达到的效果及其优缺点。

下面的各种场景均不考虑中间件的异常情况，比如 mq 异常导致消息丢失等。

2 实现方式

自底向上的事务实现方式

2.1 数据库事务实现

方式

利用了数据锁机制，mvcc 版本控制， redolog、undolog 等方式来保证一致性。

效果

数据库锁、redolog、undolog 保证了数据写入或者回滚的一致性。

mvcc 版本控制保证了数据查询范围的控制。

2.2 spring 单数据源事务实现

方式

利用 aop 切面和数据库手动提交模式，来保证一整块业务流程数据的一致性。

效果

在切面代码中的对数据库的 dml 操作都将会被事务控制。

通过代码实=现 spring事务传递机制，提供多样性的事务控制。

2.3 分布式事务实现

方式

最终一致性（RocketMQ，自实现最终一致性）

分布式事务框架 Seata

效果

实现多个分布式应用之间的数据一致性，让复杂庞大的应用能够通过拆分实现多个小应用。

3 场景分析

场景：用户下单同时扣减优惠券

3.1 单服务器实现

实现模型、流程解析

优缺点分析

优点: 系统简洁，能保证事务一致性。

缺点: 当前模型只适合单系统服务，后续订单、优惠券等功能逐渐变的庞大之后，系统协同维护成本会很高。

3.2 微服务（非分布式事务）实现

实现模型、流程解析

优缺点分析

优点: 订单系统和优惠券系统拆分，协同成本降低

缺点: 两个系统之间通过 rpc 调用，存在多种异常场景将导致数据不一致（不考虑逆向退单流程）

1. rpc 超时: 订单系统调用优惠券接口超时，优惠券系统处理完成但是返回结果超时。此时优惠券扣除成功，但是下单失败返回；
2. 系统异常: 优惠券扣除成功之后,订单系统在事务未提交之前发生异常(重启等)。此时优惠券扣除成功，订单下单失败；
3. 异常处理失败: 优惠券扣除成功,订单后续处理失败调用优惠券回滚接口失败。此时优惠券扣除成功，订单下单失败。

简单优化: 如果只是针对述场景，因为订单是存在超时未下单自动取消的业务特性。因此可以让优惠券业务可以使用 预扣除+定时回调确认方式处理(可以理解为三阶段提交)。

上述方案只是针对特定场景并不通用，但是实现方式比较轻量，对整体业务侵入较小。

3.3 微服务分布式事务实现

3.3.1 实现模型、流程解析(方式一)

优缺点分析

此种方式流程（A）存在缺陷

1. 发送消息是否需要等 ack 返回。等待 ack 影响并发效率，不等待可能发送失败但是订单下单成功；
2. 消息发送都需要放在业务的最后一步，防止消息发送成功但是后续逻辑执行异常，导致下单回滚优惠券扣除成功；
3. 系统异常：在（A）流程发送成功之后,系统重启订单系统事务未提交情况下，优惠券扣除成功。

优化: 加入上面的优惠券定时回调确认逻辑，如果订单下单失败或者不存在，预扣除数据回滚即可。

3.3.2 实现模型、流程解析(方式二)

优缺点分析

优点：

1. 解决了方式一的发送性能问题；
2. 提高了系统的容错性，通过定时任务实现多次发送消息，来弥补网络问题等异常出现导致单次失败的情况；
3. 加入了优惠券定时回调。

缺点：

相对于单服务系统来说，引入了较重的逻辑处理

3.3.2 多系统情况的扣除

多系统扣除则将消息改为广播模式，当订单下单成功了发送广播，由下游各业务方根据自身业务决定接收处理方式

4 总结

经过上述方案的不断迭代可以看出，在实现分布式事务的一致性场景下，有 2 处功能点是需要着重解决的，即发送消息和系统异常导致的错误扣除。 所以最后通过如下 2 种方式来解决：

1. 发送消息使用了类似本地事务表的模式+定时任务，来保证消息一定会发送成功
2. 异常扣除则使用了预扣除 + 定时回调确认的模式来保证异常数据回滚。

由此也能看出，系统经过上述改造，在事务上虽然能达到非常高的一致性但是或多或少都附带了较多的非常规逻辑。