日期：
来源：SpringForAll收集编辑：
来源 | OSCHINA 社区
作者 | 京东云开发者-郑朋辉
原文链接：https://my.oschina.net/u/4090830/blog/5585963
1 背景
市面上常见的有，2pc/3pc、tcc、saga 等常见的分布式事务解决方案，但是实际实施起来框架比较重，设计开发比较繁琐，不易于快速开发上手。本文提供一种基于柔性事务设计的简单易上手的分布式事务设计方案，用于解决常见的分布式事务常见场景。2 常见分布式事务场景
2.1 同步场景
常见的场景，方法内依赖外部微服务多个同步接口，等同步接口返回再展开后续逻辑，如下图 1 描述。存在的问题：B/C 失败后，A/B 不能回滚，造成数据不一致？2.2 异步场景
方法内依赖外部微服务多个同步接口同时，本地事务提交并发出异步 MQ，如下图 2 描述。存在的问题：询价系统无法保证本地事务和 mq 消息的发送同时成功或失败，会造成数据不一致。3 解决方案
3.1 数据模型设计
事务表：记录每次同步方法执行的状态，包括：1 - 进行中（同步方法执行开始）、2 - 已完成（同步方法执行成功）、3 - 失败（同步方法执行失败）、4 - 已回滚（回滚方法执行成功）；方法调用表：记录一个完整的事务内所有方法的执行前入参、同步方法接口、回滚接口、回滚入参、方法执行顺序，如下图 3 描述：3.2 设计原理
原理：一个完整事务内，1. 首先每个方法提供回滚接口，其次，事务内每次同步方法执行时，优先维护入参数据到事务表，方便后续做回滚补偿；2. 整个事务内某一个方法执行失败时，结束整个事务，并更新事务表状态 = 失败；3. 事务表通过轮询状态 status=3 (失败) 事务，调用回滚接口，利用回滚入参进行接口补偿；4. 回滚逻辑：找到事务表中失败的执行方法的顺序值，只调用小于失败顺序值的所有回滚接口、入参，注意并不回滚失败值的接口，并根据顺序倒序进行接口回滚补偿。3.3 执行时序
3.4 回滚失败处理方案：
事务服务的高可用保障：柔性事务前提是保证事务服务高可用性，重点保障；
回滚服务重试机制：回滚接口失败重试机制，保证数据一致性；
为了避免架构复杂度，做日志记录、报警、人工处理。
4 注意问题
回滚服务的幂等性：回滚做好业务防重和系统防重，防止因为回滚带来的业务数据不一致；
脏数据：整个事务中某一方法执行失败，前面调用方法的数据作为脏数据使用。简单的解决方案：依赖事务表整个事务执行状态来决定能否使用脏数据。但缺点就是这样会耦合业务逻辑；
中心化：整个事务的维护完全依赖事务服务完成，需要保证事务服务的高可用性；
实时性：事务维护本方案通过定时任务维护，如果业务场景有实时性要求，方式可以改为：在整个事务中某一方法执行失败时，catch 异常，catch 内更新任务状态成功时，直接进行回滚逻辑调用。
5 总结
除了通过常规本地大事务保证事务完整性方案，本次方案提供了一套基于柔性事务回滚补偿的方式来保证分布式事务，通过维护事务服务和事务服务中心对应数据表，从而保障整个分布式事务的完整性。实现方式简单、轻量、易于操作，方便地解决了常见分布式事务场景。关注后端面试那些事，回复【2022面经】
获取最新大厂Java面经
最后重要提示：高质量的技术交流群，限时免费开放，今年抱团最重要。想进群的，关注SpringForAll社区，回复关键词：加群，拉你进群。