摘要：你是不是也有过这样的经历？明明本地测试时事务跑得好好的，一上分布式环境就频繁出现数据不一致 —— 订单支付成功了库存没扣，用户充值到账了积分没增加，排查半天还找不到根因？
你是不是也有过这样的经历？明明本地测试时事务跑得好好的，一上分布式环境就频繁出现数据不一致 —— 订单支付成功了库存没扣，用户充值到账了积分没增加，排查半天还找不到根因？
其实不光是你，几乎每个接触分布式系统的开发都会栽在 “事务一致性” 这个坑里。这背后藏着分布式架构的核心矛盾：当业务被拆分成多个独立服务，每个服务都有自己的数据库，传统单机事务的 ACID 特性根本兜不住跨服务的数据操作。就像几个人同时打理一个仓库，没有统一的指挥，很容易出现 “有人记账有人发货，账货对不上” 的混乱。
今天就用最接地气的方式，把分布式事务的解决方案和避坑点说透，看完直接能落地！
在单机系统里，数据库的事务管理器能轻松保证 ACID：要么所有操作全成功，要么全回滚。但分布式系统里，问题变得复杂多了：
网络不是 100% 可靠的：服务 A 调用服务 B 的接口，可能出现 “成功但超时” 的诡异情况，A 以为失败要回滚，B 其实已经执行成功。数据不在一个 “篮子” 里：订单库、库存库、支付库是独立的，没有统一的事务管理器来协调它们的操作。性能与一致性的冲突：追求绝对一致可能导致系统响应变慢，牺牲一致性又会出现数据乱序，怎么平衡是个难题。这就是为什么你写的 “伪分布式事务” 总出问题 —— 只在代码里加个 try-catch，根本解决不了跨服务、跨数据库的协调问题。
这是最容易落地的方案，核心思路是 “用本地事务保证消息可靠，用消息驱动跨服务操作”，步骤特别清晰：
创建本地消息表：在发起事务的服务数据库里，建一张transaction_message表，字段包括消息 ID、业务 ID、接收服务、消息内容、状态（待发送 / 已发送 / 已完成）。本地事务 + 写消息：比如 “下单扣库存” 场景，在订单服务的本地事务里，同时完成 “创建订单” 和 “写入扣库存消息”，两者要么全成要么全败。消息投递与重试：用定时任务扫描 “待发送” 消息，调用库存服务的扣减接口。如果调用失败，记录重试次数，达到阈值就告警人工介入。更新消息状态：库存服务扣减成功后，给订单服务返回确认，订单服务将消息状态改成 “已完成”。这个方案的优点是不依赖中间件，开发成本低；缺点是消息表与业务耦合，高并发下定时任务可能成为瓶颈。
Seata 是阿里开源的分布式事务框架，AT 模式是最常用的，本质是 “两阶段提交” 的优化，对开发几乎透明：
初始化：在每个参与事务的服务里引入 Seata 依赖，配置事务组 ID，启动时会向 Seata Server 注册。标记全局事务：在发起方的方法上加@GlobalTransactional注解，比如订单服务的createOrder方法。第一阶段（执行本地事务）：订单服务调用库存服务时，Seata 会生成全局事务 ID，通过拦截器传递给库存服务。库存服务执行 “扣减库存”，同时 Seata 的 RM（资源管理器）会自动生成 undo log（回滚日志），记录扣减前的库存数量。所有服务本地事务执行成功后，向 Seata Server 汇报 “可提交”。第二阶段（提交 / 回滚）：如果所有服务都汇报 “可提交”，Seata Server 下达 “提交” 指令，各服务删除 undo log，事务完成。如果有服务汇报 “失败”，Seata Server 下达 “回滚” 指令，各服务根据 undo log 恢复数据，比如把库存改回扣减前的数值。AT 模式的优点是开发侵入性低，性能比传统 2PC 好；缺点是需要部署 Seata Server，对数据库有一定性能影响（要写 undo log）。
如果你的业务链路特别长，比如 “下单→扣库存→支付→减余额→发积分→通知物流”，用前两种方案可能会因为超时导致失败，这时候 Saga 模式就派上用场了：
拆分事务步骤：把长事务拆成多个短事务，每个短事务对应一个服务的操作，比如 T1（创建订单）、T2（扣库存）、T3（处理支付）、T4（发积分）。定义补偿事务：为每个短事务设计对应的补偿操作，比如 C2（恢复库存）、C3（退款）、C4（扣回积分），补偿操作必须是幂等的（重复执行不影响结果）。顺序执行与补偿：正常情况：按 T1→T2→T3→T4 的顺序执行，全部成功则事务完成。异常情况：比如 T3 执行失败，就按 C3→C2→C1 的顺序反向执行补偿事务，把之前的操作回滚。Saga 模式的优点是支持长事务，性能好；缺点是只能保证最终一致性，补偿逻辑的设计比较复杂，还要处理 “补偿失败” 的极端情况。
忽略幂等性：重试机制是解决分布式问题的常用手段，但如果接口不幂等，重试一次就会多扣一次库存。解决办法：给每个请求加唯一 ID，服务端校验 ID 是否已处理过。
滥用 “强一致性”：不是所有场景都需要实时一致，比如积分发放延迟 1 分钟用户根本感知不到，用最终一致性方案能大幅提升性能。
日志打印不规范：出问题时找不到关键日志，排查效率极低。建议在事务的每个节点打印全局事务 ID、业务 ID、操作前后的数据快照。
没考虑中间件故障：比如 Seata Server 挂了怎么办？要做好降级方案，比如暂时切换到本地消息表模式，或者人工介入处理。
看完这 3 套方案你会发现，分布式事务根本没有 “一招鲜” 的完美解决方案：本地消息表适合小团队快速落地，Seata AT 模式适合标准微服务架构，Saga 模式适合长事务场景。
我们能做的，是先明确业务的一致性要求 —— 是 “必须实时一致” 还是 “最终一致即可”？再结合团队技术栈和系统性能瓶颈，选择最适配的方案。甚至很多时候，还需要把不同方案结合起来用，比如核心环节用 Seata 保证强一致，非核心环节用本地消息表保证最终一致。
最后想问一句：你在项目中踩过哪些分布式事务的坑？当时是用什么方法解决的？欢迎在评论区分享你的经验，咱们一起避坑升级！
来源：小贝课堂