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 调用，存在多种异常场景将导致数据不一致（不考虑逆向退单流程）
简单优化: 如果只是针对述场景，因为订单是存在超时未下单自动取消的业务特性。因此可以让优惠券业务可以使用 预扣除+定时回调确认方式处理(可以理解为三阶段提交)。
上述方案只是针对特定场景并不通用，但是实现方式比较轻量，对整体业务侵入较小。
3.3 微服务分布式事务实现
3.3.1 实现模型、流程解析(方式一)
优缺点分析
此种方式流程（A）存在缺陷
优化: 加入上面的优惠券定时回调确认逻辑，如果订单下单失败或者不存在，预扣除数据回滚即可。
3.3.2 实现模型、流程解析(方式二)
优缺点分析
优点：
缺点：
相对于单服务系统来说，引入了较重的逻辑处理
3.3.2 多系统情况的扣除
多系统扣除则将消息改为广播模式，当订单下单成功了发送广播，由下游各业务方根据自身业务决定接收处理方式
4 总结
经过上述方案的不断迭代可以看出，在实现分布式事务的一致性场景下，有 2 处功能点是需要着重解决的，即发送消息和系统异常导致的错误扣除。 所以最后通过如下 2 种方式来解决：
由此也能看出，系统经过上述改造，在事务上虽然能达到非常高的一致性但是或多或少都附带了较多的非常规逻辑。
推荐阅读
Java 动态编译在项目中的实践
RocketMQ DLedger 初识
一种基于布隆过滤器的大表计算优化方法
业务系统 hystrix 实际应用
图数据技术调研以及业务实践
招贤纳士
政采云技术团队（Zero），Base 杭州，一个富有激情和技术匠心精神的成长型团队。规模 500 人左右，在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。
如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com
微信公众号
文章同步发布，政采云技术团队公众号，欢迎关注
