事务探索

闪念基因 08-26 581

前言：

而今大家对“简述事务的四个特性和每种特性的说明”大约比较注意，我们都想要剖析一些“简述事务的四个特性和每种特性的说明”的相关知识。那么小编在网上搜集了一些关于“简述事务的四个特性和每种特性的说明””的相关知识，希望兄弟们能喜欢，大家快快来学习一下吧！

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 调用，存在多种异常场景将导致数据不一致（不考虑逆向退单流程）

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

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

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

3.3 微服务分布式事务实现3.3.1 实现模型、流程解析(方式一)

优缺点分析

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

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

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

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

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

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

3.3.2 多系统情况的扣除

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