1. 项目概述为什么分布式事务是每个后端工程师的必修课干了这么多年后端我越来越觉得分布式事务这个话题就像一座绕不开的山。你可能会说我的系统现在很简单就一个单体应用一个数据库事务有数据库的ACID保证稳得很。但业务一旦跑起来用户量上来服务拆分、数据库分库分表几乎是必然的选择。这时候原本在数据库内部“原子性”执行的一系列操作被拆分到了不同的服务、不同的数据库实例上怎么保证它们要么一起成功要么一起失败这就是分布式事务要解决的核心问题。想想一个最经典的电商场景用户下单。这个动作背后至少涉及“订单服务”创建订单记录和“库存服务”扣减商品库存。如果订单创建成功了但库存扣减因为网络波动失败了用户就会付了钱却买不到货反过来如果库存扣减成功但订单记录没写进去库存就白白损失了。在单体架构里一个数据库事务就能搞定但在微服务架构下这两个操作分属两个独立的服务各自管理自己的数据库传统的本地事务Local Transaction就彻底失效了。这就是典型的分布式事务问题它关乎数据的一致性直接影响到用户体验和公司的真金白银。所以今天我想结合自己踩过的坑和积累的经验把分布式事务里里外外掰开揉碎了讲清楚。我们不只讲那些“两阶段提交2PC”、“TCC”、“SAGA”这些听起来高大上的名词更要讲清楚它们各自在什么场景下用、怎么选型、实操时有哪些暗坑。我会用“订单扣库存”这个贯穿始终的例子带你从理论到实践走一遍。无论你是正在为数据不一致而头疼的工程师还是想提前储备知识的开发者这篇内容都能给你一套清晰的解决思路和可落地的方案参考。2. 分布式事务的核心挑战与基础理论在深入方案之前我们必须先理解分布式事务到底难在哪里。它和我们熟悉的本地事务有本质区别。2.1 从ACID到CAP/BASE理念的变迁本地事务我们追求的是ACID原子性Atomicity事务内的操作要么全做要么全不做。一致性Consistency事务执行前后数据库从一个一致状态转变到另一个一致状态业务规则约束。隔离性Isolation并发事务之间互不干扰。持久性Durability事务提交后对数据的修改是永久性的。在单数据库环境下数据库管理系统如MySQL通过锁、日志Redo/Undo Log等机制完美地提供了ACID保证。但一旦事务参与者分布在网络的不同节点上我们就必须面对分布式系统的核心定理——CAP定理。CAP定理指出一个分布式系统不可能同时满足以下三点一致性Consistency所有节点在同一时间看到的数据是完全相同的强一致性。可用性Availability每个请求都能收到一个非错的响应但不保证是最新数据。分区容错性Partition tolerance系统在遇到网络分区部分节点无法通信时仍能继续对外提供服务。由于网络分区在分布式系统中是必然存在的P必须满足所以我们实际上是在C一致性和A可用性之间做权衡。追求强一致性如基于2PC的方案就可能在网络异常时牺牲可用性服务等待、超时、阻塞追求高可用性就往往需要接受最终一致性Eventually Consistency。这就引出了BASE理论它是对CAP中一致性和可用性权衡的结果基本可用Basically Available系统出现故障时允许损失部分可用性如响应时间变长、功能降级。软状态Soft State允许系统中的数据存在中间状态并且该状态不影响系统整体可用性。最终一致性Eventually Consistent经过一段时间后所有数据副本最终会达到一致的状态。 注意理解CAP和BASE是选择分布式事务方案的基石。没有一种方案能完美实现分布式下的ACID我们都是在根据业务场景在一致性、可用性和性能之间寻找最佳平衡点。2.2 分布式事务的典型场景与核心问题除了开头的“下单扣库存”分布式事务无处不在银行转账从A账户扣款向B账户加款。必须同时成功或失败。发布文章文章写入主库后需要同步到搜索引擎的索引库、更新缓存等。跨服务数据更新用户中心更新了头像需要通知社交服务、内容服务等更新相关展示。这些场景会暴露出几个核心问题网络通信不可靠请求可能丢失、重复、超时。节点故障任何参与事务的服务或数据库都可能随时宕机。时钟不同步不同机器的时间可能存在微小差异给基于超时的判断带来困难。正是这些问题使得实现一个健壮的分布式事务方案异常复杂。接下来我们就逐一拆解主流的解决方案。3. 主流分布式事务方案深度解析与选型指南市面上方案很多但归根结底可以分为两大类强一致性方案和最终一致性方案。强一致性方案试图在分布式环境下模拟ACID代价是复杂性和性能最终一致性方案则拥抱BASE理论通过补偿等手段保证数据的最终正确。3.1 强一致性方案两阶段提交2PC及其变种2PC是最经典的分布式事务协议它引入了一个协调者Coordinator的角色来管理多个参与者Participant的事务。第一阶段提交请求投票阶段协调者向所有参与者发送“准备提交Prepare”请求并附带事务内容。参与者执行本地事务的所有操作写Undo/Redo Log锁定相关资源但不提交。参与者向协调者反馈响应成功Yes或失败No。第二阶段执行提交提交/回滚阶段如果协调者收到所有参与者的“Yes”响应则发送“提交Commit”指令。如果有任何一个参与者返回“No”或超时则发送“回滚Rollback”指令。参与者收到指令后执行真正的提交或回滚操作并释放锁资源向协调者发送确认Ack。优点原理简单强一致性保证。缺点同步阻塞在准备阶段参与者会锁定资源直到第二阶段完成。期间其他事务无法访问这些资源性能差。单点问题协调者至关重要一旦宕机参与者将一直处于不确定状态阻塞。数据不一致在第二阶段如果协调者发送了Commit指令后宕机且只有部分参与者收到了指令就会导致部分提交、部分未提交的数据不一致。实操心得原生2PC在互联网高并发场景下很少直接使用因为它的阻塞特性无法接受。但它是一些其他方案的理论基础。在实际中我们通常使用其改进版或通过中间件如Seata的AT模式来规避部分问题。3.2 最终一致性方案补偿型事务TCCTCCTry-Confirm-Cancel是一种业务侵入性较强的最终一致性方案。它要求开发者将业务逻辑明确地拆分为三个操作Try尝试完成所有业务的检查并预留好所需的业务资源。例如下单场景中Try阶段不是直接扣库存而是将库存“冻结”起来status frozen同时订单状态为“待确认”。Confirm确认真正执行业务操作使用Try阶段预留的资源。此操作需满足幂等性。例如将冻结的库存扣减掉stock stock - frozen_qty订单状态改为“已确认”。Cancel取消释放Try阶段预留的业务资源。此操作也需满足幂等性。例如解冻库存status available订单状态改为“已取消”。TCC的事务管理器负责控制整个流程先调用所有参与服务的Try全部成功则调用Confirm任一Try失败则调用Cancel。优点避免了长事务对资源的锁定性能较好。数据最终一致性保证较好。缺点业务侵入性强需要改造原有业务逻辑设计并实现三个接口开发成本高。实现复杂需要考虑空回滚Try未执行却收到了Cancel、幂等、防悬挂Cancel比Try先到等异常情况。 提示TCC非常适合执行时间较短的业务如资金交易、库存处理。在实现时务必为每个分布式事务生成全局唯一的XID并在Try阶段将XID与预留资源绑定这样在Confirm/Cancel时才能找到对应的资源进行操作。同时三个接口都必须实现幂等通常通过事务状态表记录XID和当前阶段来判断是否已执行过。3.3 最终一致性方案基于消息队列的最终一致性这是互联网公司最常用、性价比最高的方案之一。其核心思想是将需要分布式事务处理的多个操作拆分为一个本地事务和一个或多个异步消息任务。还是以下单为例订单服务本地事务在一个数据库事务中执行①插入订单记录状态为“待支付”②向本地消息表插入一条“扣减库存消息”状态为“待发送”。这个操作是关键它保证了业务操作和消息记录的原子性。消息投递有一个定时任务扫描本地消息表中“待发送”的消息将其投递到消息队列如RocketMQ、Kafka。投递成功后更新本地消息状态为“已发送”。库存服务消费库存服务订阅该消息执行本地库存扣减事务。扣减成功后向消息队列返回消费成功确认ACK。兜底补偿如果库存服务消费失败消息队列会根据重试策略重新投递。如果达到最大重试次数仍失败消息会进入死信队列需要人工或自动告警介入处理。同时订单服务也需要一个定时任务检查长时间处于“待支付”但库存未扣的订单进行取消或重新触发补偿。这个方案有一个著名的变种叫做“最大努力通知”。它适用于对一致性要求不是那么极端严格的场景。比如支付成功后通知商户。支付中心会先同步调用商户接口通知如果失败则通过定时任务异步重试调用可能是多次即“最大努力”并记录通知结果。即使最终通知失败也往往有对账等后续补救措施而不是无限期阻塞主流程。优点吞吐量高本地事务性能好异步消息解耦。通用性强对业务侵入小只需增加一个消息表。系统扩展性好服务间通过消息异步通信。缺点延迟数据一致性是异步实现的存在短暂延迟。复杂度转移需要保证消息可靠投递、幂等消费并设计好补偿机制。实操心得本地消息表是此方案的核心。消息表字段至少应包含id,biz_id业务唯一标识如订单号,biz_type,msg_content,status待发送/已发送/已完成,retry_count,next_retry_time,created_time。务必确保业务操作和插入消息在同一个数据库事务中。消费端必须实现幂等可以通过biz_id来判断是否已处理过。3.4 最终一致性方案SAGA事务模式SAGA模式适用于业务流程长、涉及服务多的场景。它将一个分布式事务拆分为一系列本地事务每个本地事务都有对应的补偿操作。SAGA有两种执行方式协同式Choreography每个服务执行完本地事务后发布一个事件下一个服务监听该事件并执行自己的事务。事件流驱动整个流程。补偿则是反向执行一系列补偿事件。编排式Orchestration引入一个SAGA协调器Orchestrator以命令/调用的方式告诉每个参与者该执行什么操作事务或补偿。优点避免了长事务锁适合长流程业务。缺点补偿操作难设计不是所有操作都能轻松实现可补偿的例如发送短信通知。可能脏读由于事务分段提交中间状态可能被其他业务读到。选型对比速查表特性两阶段提交 (2PC)TCC本地消息表MQSAGA一致性强一致性最终一致性最终一致性最终一致性性能差同步阻塞好无锁好异步好异步业务侵入低非常高改业务逻辑低加消息表中定义补偿复杂度中协调者逻辑高异常处理复杂中保证消息可靠高流程编排适用场景数据库层XA协议短流程、需强隔离的资金业务高并发、最终一致可接受的互联网业务长流程业务如旅行订票4. 基于Seata的一站式分布式事务解决方案实战理解了理论我们来看一个能降低实操难度的利器——Seata。Seata是阿里开源的分布式事务解决方案它提供了AT、TCC、SAGA、XA等多种模式。这里重点讲最常用的AT模式它是对2PC的优化实现了对业务代码几乎无侵入的分布式事务。4.1 Seata AT模式核心原理AT模式同样分两阶段但无需我们手动编写补偿逻辑。第一阶段Seata会拦截业务SQL解析语义保存更新前的数据镜像Before Image和更新后的数据镜像After Image到全局事务关联的undo_log表中。然后执行业务SQL提交本地事务。这样本地锁就很快释放了。-- 以扣减库存为例Seata代理后实际执行 -- 1. 查询前置镜像 (Before Image): SELECT id, stock FROM item WHERE id 1; -- 2. 执行业务SQL: UPDATE item SET stock stock - 1 WHERE id 1; -- 3. 查询后置镜像 (After Image): SELECT id, stock FROM item WHERE id 1; -- 4. 插入undo_log: INSERT INTO undo_log (xid, branch_id, context, rollback_info, log_status) VALUES (...); -- 5. 提交本地事务。第二阶段提交因为一阶段已经提交所以二阶段提交时Seata协调者只需异步删除各参与者的undo_log即可速度极快。回滚协调者通知参与者回滚。参与者根据XID找到对应的undo_log利用Before Image生成反向更新SQL回滚SQL并执行然后删除undo_log完成回滚。关键点AT模式的一阶段就提交了本地事务释放了锁所以性能比传统2PC好很多。它通过undo_log保证了回滚能力。4.2 Seata Server与客户端的部署与配置1. 部署Seata ServerTC-事务协调者Seata Server需要独立部署负责维护全局事务的状态和驱动全局提交/回滚。下载从GitHub Release页面下载Server包。配置存储模式Seata Server需要存储全局事务、分支事务、锁信息。支持file单机测试、db生产推荐、redis等。如果选db需要创建global_table,branch_table,lock_table三张表并修改conf/file.conf中的store.modedb以及数据库连接信息。配置注册中心修改conf/registry.conf指定TC如何被客户端发现。常用Nacos。registry { type nacos nacos { application seata-server serverAddr 127.0.0.1:8848 group SEATA_GROUP namespace cluster default } }启动sh bin/seata-server.sh2. 业务服务集成Seata Client每个参与分布式事务的微服务都需要引入Seata Client。引入依赖在Spring Boot项目中加入seata-spring-boot-starter。配置在application.yml中配置Seata。seata: application-id: your-service-name tx-service-group: my_tx_group # 事务组需与TC配置对应 service: vgroup-mapping: my_tx_group: default # 映射到TC的集群名 registry: type: nacos nacos: server-addr: 127.0.0.1:8848 group: SEATA_GROUP config: type: nacos nacos: server-addr: 127.0.0.1:8848 group: SEATA_GROUP >Service public class OrderServiceImpl implements OrderService { GlobalTransactional(name createOrder, rollbackFor Exception.class) public Order createOrder(OrderDTO orderDTO) { // 1. 本地创建订单 orderMapper.insert(order); // 2. 远程调用库存服务扣减库存 storageFeignClient.deduct(orderDTO.getProductId(), orderDTO.getCount()); // 如果此处或后续逻辑抛出异常Seata会触发全局回滚 // 3. 其他业务... return order; } }库存服务方法只需在方法上添加Transactional本地事务和GlobalTransactional的传播属性即可通常不需要除非它自身也是全局事务入口。4.3 一个完整的“下单-扣库存”AT模式事务流程假设订单服务端口8080和库存服务端口8081都已集成Seata Client且TC已启动。用户请求下单进入OrderService.createOrder()方法。Seata拦截到GlobalTransactional注解向TCSeata Server发起全局事务的开启请求。TC生成一个全局唯一的XID如192.168.1.1:8091:123456789并返回给订单服务。这个XID会在整个调用链中传播。订单服务执行本地orderMapper.insert。Seata数据源代理会生成一个分支事务IDBranch ID。在执行INSERT前查询前置数据镜像此处无。执行INSERT。查询后置数据镜像新插入的行。将前后镜像、SQL类型等信息作为回滚日志插入到订单数据库的undo_log表中。提交订单服务的本地事务。订单服务通过Feign调用库存服务的deduct接口XID会通过请求头如Seata-Xid自动传递。库存服务收到请求执行业务逻辑stockMapper.deduct。Seata数据源代理同样会生成该服务下的分支事务ID。执行UPDATE前查询当前库存值Before Image。执行UPDATE扣减库存。执行后查询库存新值After Image。将回滚日志插入库存数据库的undo_log。提交库存服务的本地事务。如果所有步骤成功OrderService.createOrder()方法执行完毕。Seata Client会向TC汇报全局事务完成TC驱动第二阶段——异步删除订单和库存数据库中的undo_log记录。如果在步骤5扣减库存时失败如库存不足抛异常异常会传播回订单服务。被GlobalTransactional注解感知后订单服务会向TC汇报全局事务失败。TC会向所有已注册的分支事务订单分支、库存分支发起回滚请求。各服务收到回滚请求后根据XID查找本地的undo_log生成并执行反向SQL订单分支是DELETE库存分支是UPDATE还原库存完成数据回滚。整个过程中业务开发者只需关注业务代码和添加一个GlobalTransactional注解复杂的日志记录、事务协调、回滚操作都由Seata框架自动完成实现了对业务代码的低侵入。5. 分布式事务实践中的常见“坑”与应对策略理论很美好实践却总是磕磕绊绊。下面是我总结的几个高频问题及解决办法。5.1 幂等性问题请求重试的噩梦在分布式环境下网络超时、服务抖动可能导致调用方重试从而产生重复请求。如果服务接口不幂等就会导致数据错误如扣了两次库存。解决方案数据库唯一约束利用业务唯一键如“订单号商品ID”作为联合唯一索引重复插入会失败。状态机在业务数据中增加状态字段。只有处于特定状态如“待处理”的请求才被执行执行后更新状态。重复请求会因为状态不匹配而被忽略。Token机制调用方先向服务方申请一个全局唯一的Token。调用业务接口时携带此Token。服务方在Redis中检查setnx Token “processing”如果设置成功表示第一次请求则执行业务完成后将Token值改为“done”如果设置失败Token已存在则判断是“processing”还是“done”分别返回“处理中”或“已处理”结果。分布式锁对于更复杂的非幂等操作可以使用分布式锁如基于Redis确保同一业务键在同一时刻只有一个请求能进入核心逻辑。 提示幂等性设计应是消费端服务提供方的责任不能依赖调用方不重试。在MQ消费、RPC接口设计中必须首要考虑幂等。5.2 空回滚与业务悬挂这是TCC模式下的典型问题在Seata的TCC模式中也会遇到。空回滚Try阶段因网络超时未执行但TC收到了Try失败的报告触发了全局回滚从而调用了Cancel。此时Cancel需要处理“未执行Try却收到Cancel”的情况。业务悬挂Cancel比Try请求先到达网络拥堵导致。Cancel执行了空回滚之后Try请求才到达并执行预留的资源再也无法被Confirm或Cancel处理。解决方案在Try阶段将全局事务XID和分支事务ID关联的业务数据如冻结记录插入数据库。这是关键的一步。在Cancel阶段先检查是否存在对应的Try记录。如果不存在说明是空回滚则记录一条状态为“已空回滚”的日志并直接返回成功。在Try阶段同样先检查是否存在该XID的Cancel记录空回滚记录。如果存在则拒绝执行Try防止业务悬挂。5.3 数据不一致的监控与补偿即使采用了成熟的方案在极端情况下如长时间网络分区、多个节点同时故障仍可能出现数据不一致。因此必须建立监控和对账补偿机制。监控事务状态监控监控Seata TC中长时间未完成悬挂的全局事务。日志告警监控错误日志特别是事务回滚、重试失败的日志。业务指标监控监控关键业务数据如“已支付订单数”与“已扣库存数”的差值趋势。对账补偿离线对账每天定时跑对账任务核对不同系统间的核心数据如订单库的订单状态与库存库的库存流水。发现不一致记录生成差错单。实时核对在关键业务流程中在事务完成后发送一条核对消息到消息队列由一个独立的核对服务消费实时检查关联数据的一致性。补偿作业对于对账发现的差错根据业务规则设计自动或半自动的补偿脚本。例如发现订单成功但库存未扣可以尝试调用库存服务的补偿接口进行扣减或通知运营人员人工处理。实操心得分布式事务方案选型没有银弹。对于核心的、实时性要求高的资金交易可考虑TCC。对于绝大部分互联网业务场景基于消息队列的最终一致性方案是性价比最高的选择配合完善的监控和对账能解决99%的问题。而Seata AT模式则为希望以较低侵入性获得分布式事务能力的团队提供了一个很好的折中选择但在高性能场景下需要注意其全局锁可能带来的性能影响。最终理解业务容忍度能接受多久的不一致是做出正确技术选型的第一步。
1. 项目概述为什么分布式事务是每个后端工程师的必修课干了这么多年后端我越来越觉得分布式事务这个话题就像一座绕不开的山。你可能会说我的系统现在很简单就一个单体应用一个数据库事务有数据库的ACID保证稳得很。但业务一旦跑起来用户量上来服务拆分、数据库分库分表几乎是必然的选择。这时候原本在数据库内部“原子性”执行的一系列操作被拆分到了不同的服务、不同的数据库实例上怎么保证它们要么一起成功要么一起失败这就是分布式事务要解决的核心问题。想想一个最经典的电商场景用户下单。这个动作背后至少涉及“订单服务”创建订单记录和“库存服务”扣减商品库存。如果订单创建成功了但库存扣减因为网络波动失败了用户就会付了钱却买不到货反过来如果库存扣减成功但订单记录没写进去库存就白白损失了。在单体架构里一个数据库事务就能搞定但在微服务架构下这两个操作分属两个独立的服务各自管理自己的数据库传统的本地事务Local Transaction就彻底失效了。这就是典型的分布式事务问题它关乎数据的一致性直接影响到用户体验和公司的真金白银。所以今天我想结合自己踩过的坑和积累的经验把分布式事务里里外外掰开揉碎了讲清楚。我们不只讲那些“两阶段提交2PC”、“TCC”、“SAGA”这些听起来高大上的名词更要讲清楚它们各自在什么场景下用、怎么选型、实操时有哪些暗坑。我会用“订单扣库存”这个贯穿始终的例子带你从理论到实践走一遍。无论你是正在为数据不一致而头疼的工程师还是想提前储备知识的开发者这篇内容都能给你一套清晰的解决思路和可落地的方案参考。2. 分布式事务的核心挑战与基础理论在深入方案之前我们必须先理解分布式事务到底难在哪里。它和我们熟悉的本地事务有本质区别。2.1 从ACID到CAP/BASE理念的变迁本地事务我们追求的是ACID原子性Atomicity事务内的操作要么全做要么全不做。一致性Consistency事务执行前后数据库从一个一致状态转变到另一个一致状态业务规则约束。隔离性Isolation并发事务之间互不干扰。持久性Durability事务提交后对数据的修改是永久性的。在单数据库环境下数据库管理系统如MySQL通过锁、日志Redo/Undo Log等机制完美地提供了ACID保证。但一旦事务参与者分布在网络的不同节点上我们就必须面对分布式系统的核心定理——CAP定理。CAP定理指出一个分布式系统不可能同时满足以下三点一致性Consistency所有节点在同一时间看到的数据是完全相同的强一致性。可用性Availability每个请求都能收到一个非错的响应但不保证是最新数据。分区容错性Partition tolerance系统在遇到网络分区部分节点无法通信时仍能继续对外提供服务。由于网络分区在分布式系统中是必然存在的P必须满足所以我们实际上是在C一致性和A可用性之间做权衡。追求强一致性如基于2PC的方案就可能在网络异常时牺牲可用性服务等待、超时、阻塞追求高可用性就往往需要接受最终一致性Eventually Consistency。这就引出了BASE理论它是对CAP中一致性和可用性权衡的结果基本可用Basically Available系统出现故障时允许损失部分可用性如响应时间变长、功能降级。软状态Soft State允许系统中的数据存在中间状态并且该状态不影响系统整体可用性。最终一致性Eventually Consistent经过一段时间后所有数据副本最终会达到一致的状态。 注意理解CAP和BASE是选择分布式事务方案的基石。没有一种方案能完美实现分布式下的ACID我们都是在根据业务场景在一致性、可用性和性能之间寻找最佳平衡点。2.2 分布式事务的典型场景与核心问题除了开头的“下单扣库存”分布式事务无处不在银行转账从A账户扣款向B账户加款。必须同时成功或失败。发布文章文章写入主库后需要同步到搜索引擎的索引库、更新缓存等。跨服务数据更新用户中心更新了头像需要通知社交服务、内容服务等更新相关展示。这些场景会暴露出几个核心问题网络通信不可靠请求可能丢失、重复、超时。节点故障任何参与事务的服务或数据库都可能随时宕机。时钟不同步不同机器的时间可能存在微小差异给基于超时的判断带来困难。正是这些问题使得实现一个健壮的分布式事务方案异常复杂。接下来我们就逐一拆解主流的解决方案。3. 主流分布式事务方案深度解析与选型指南市面上方案很多但归根结底可以分为两大类强一致性方案和最终一致性方案。强一致性方案试图在分布式环境下模拟ACID代价是复杂性和性能最终一致性方案则拥抱BASE理论通过补偿等手段保证数据的最终正确。3.1 强一致性方案两阶段提交2PC及其变种2PC是最经典的分布式事务协议它引入了一个协调者Coordinator的角色来管理多个参与者Participant的事务。第一阶段提交请求投票阶段协调者向所有参与者发送“准备提交Prepare”请求并附带事务内容。参与者执行本地事务的所有操作写Undo/Redo Log锁定相关资源但不提交。参与者向协调者反馈响应成功Yes或失败No。第二阶段执行提交提交/回滚阶段如果协调者收到所有参与者的“Yes”响应则发送“提交Commit”指令。如果有任何一个参与者返回“No”或超时则发送“回滚Rollback”指令。参与者收到指令后执行真正的提交或回滚操作并释放锁资源向协调者发送确认Ack。优点原理简单强一致性保证。缺点同步阻塞在准备阶段参与者会锁定资源直到第二阶段完成。期间其他事务无法访问这些资源性能差。单点问题协调者至关重要一旦宕机参与者将一直处于不确定状态阻塞。数据不一致在第二阶段如果协调者发送了Commit指令后宕机且只有部分参与者收到了指令就会导致部分提交、部分未提交的数据不一致。实操心得原生2PC在互联网高并发场景下很少直接使用因为它的阻塞特性无法接受。但它是一些其他方案的理论基础。在实际中我们通常使用其改进版或通过中间件如Seata的AT模式来规避部分问题。3.2 最终一致性方案补偿型事务TCCTCCTry-Confirm-Cancel是一种业务侵入性较强的最终一致性方案。它要求开发者将业务逻辑明确地拆分为三个操作Try尝试完成所有业务的检查并预留好所需的业务资源。例如下单场景中Try阶段不是直接扣库存而是将库存“冻结”起来status frozen同时订单状态为“待确认”。Confirm确认真正执行业务操作使用Try阶段预留的资源。此操作需满足幂等性。例如将冻结的库存扣减掉stock stock - frozen_qty订单状态改为“已确认”。Cancel取消释放Try阶段预留的业务资源。此操作也需满足幂等性。例如解冻库存status available订单状态改为“已取消”。TCC的事务管理器负责控制整个流程先调用所有参与服务的Try全部成功则调用Confirm任一Try失败则调用Cancel。优点避免了长事务对资源的锁定性能较好。数据最终一致性保证较好。缺点业务侵入性强需要改造原有业务逻辑设计并实现三个接口开发成本高。实现复杂需要考虑空回滚Try未执行却收到了Cancel、幂等、防悬挂Cancel比Try先到等异常情况。 提示TCC非常适合执行时间较短的业务如资金交易、库存处理。在实现时务必为每个分布式事务生成全局唯一的XID并在Try阶段将XID与预留资源绑定这样在Confirm/Cancel时才能找到对应的资源进行操作。同时三个接口都必须实现幂等通常通过事务状态表记录XID和当前阶段来判断是否已执行过。3.3 最终一致性方案基于消息队列的最终一致性这是互联网公司最常用、性价比最高的方案之一。其核心思想是将需要分布式事务处理的多个操作拆分为一个本地事务和一个或多个异步消息任务。还是以下单为例订单服务本地事务在一个数据库事务中执行①插入订单记录状态为“待支付”②向本地消息表插入一条“扣减库存消息”状态为“待发送”。这个操作是关键它保证了业务操作和消息记录的原子性。消息投递有一个定时任务扫描本地消息表中“待发送”的消息将其投递到消息队列如RocketMQ、Kafka。投递成功后更新本地消息状态为“已发送”。库存服务消费库存服务订阅该消息执行本地库存扣减事务。扣减成功后向消息队列返回消费成功确认ACK。兜底补偿如果库存服务消费失败消息队列会根据重试策略重新投递。如果达到最大重试次数仍失败消息会进入死信队列需要人工或自动告警介入处理。同时订单服务也需要一个定时任务检查长时间处于“待支付”但库存未扣的订单进行取消或重新触发补偿。这个方案有一个著名的变种叫做“最大努力通知”。它适用于对一致性要求不是那么极端严格的场景。比如支付成功后通知商户。支付中心会先同步调用商户接口通知如果失败则通过定时任务异步重试调用可能是多次即“最大努力”并记录通知结果。即使最终通知失败也往往有对账等后续补救措施而不是无限期阻塞主流程。优点吞吐量高本地事务性能好异步消息解耦。通用性强对业务侵入小只需增加一个消息表。系统扩展性好服务间通过消息异步通信。缺点延迟数据一致性是异步实现的存在短暂延迟。复杂度转移需要保证消息可靠投递、幂等消费并设计好补偿机制。实操心得本地消息表是此方案的核心。消息表字段至少应包含id,biz_id业务唯一标识如订单号,biz_type,msg_content,status待发送/已发送/已完成,retry_count,next_retry_time,created_time。务必确保业务操作和插入消息在同一个数据库事务中。消费端必须实现幂等可以通过biz_id来判断是否已处理过。3.4 最终一致性方案SAGA事务模式SAGA模式适用于业务流程长、涉及服务多的场景。它将一个分布式事务拆分为一系列本地事务每个本地事务都有对应的补偿操作。SAGA有两种执行方式协同式Choreography每个服务执行完本地事务后发布一个事件下一个服务监听该事件并执行自己的事务。事件流驱动整个流程。补偿则是反向执行一系列补偿事件。编排式Orchestration引入一个SAGA协调器Orchestrator以命令/调用的方式告诉每个参与者该执行什么操作事务或补偿。优点避免了长事务锁适合长流程业务。缺点补偿操作难设计不是所有操作都能轻松实现可补偿的例如发送短信通知。可能脏读由于事务分段提交中间状态可能被其他业务读到。选型对比速查表特性两阶段提交 (2PC)TCC本地消息表MQSAGA一致性强一致性最终一致性最终一致性最终一致性性能差同步阻塞好无锁好异步好异步业务侵入低非常高改业务逻辑低加消息表中定义补偿复杂度中协调者逻辑高异常处理复杂中保证消息可靠高流程编排适用场景数据库层XA协议短流程、需强隔离的资金业务高并发、最终一致可接受的互联网业务长流程业务如旅行订票4. 基于Seata的一站式分布式事务解决方案实战理解了理论我们来看一个能降低实操难度的利器——Seata。Seata是阿里开源的分布式事务解决方案它提供了AT、TCC、SAGA、XA等多种模式。这里重点讲最常用的AT模式它是对2PC的优化实现了对业务代码几乎无侵入的分布式事务。4.1 Seata AT模式核心原理AT模式同样分两阶段但无需我们手动编写补偿逻辑。第一阶段Seata会拦截业务SQL解析语义保存更新前的数据镜像Before Image和更新后的数据镜像After Image到全局事务关联的undo_log表中。然后执行业务SQL提交本地事务。这样本地锁就很快释放了。-- 以扣减库存为例Seata代理后实际执行 -- 1. 查询前置镜像 (Before Image): SELECT id, stock FROM item WHERE id 1; -- 2. 执行业务SQL: UPDATE item SET stock stock - 1 WHERE id 1; -- 3. 查询后置镜像 (After Image): SELECT id, stock FROM item WHERE id 1; -- 4. 插入undo_log: INSERT INTO undo_log (xid, branch_id, context, rollback_info, log_status) VALUES (...); -- 5. 提交本地事务。第二阶段提交因为一阶段已经提交所以二阶段提交时Seata协调者只需异步删除各参与者的undo_log即可速度极快。回滚协调者通知参与者回滚。参与者根据XID找到对应的undo_log利用Before Image生成反向更新SQL回滚SQL并执行然后删除undo_log完成回滚。关键点AT模式的一阶段就提交了本地事务释放了锁所以性能比传统2PC好很多。它通过undo_log保证了回滚能力。4.2 Seata Server与客户端的部署与配置1. 部署Seata ServerTC-事务协调者Seata Server需要独立部署负责维护全局事务的状态和驱动全局提交/回滚。下载从GitHub Release页面下载Server包。配置存储模式Seata Server需要存储全局事务、分支事务、锁信息。支持file单机测试、db生产推荐、redis等。如果选db需要创建global_table,branch_table,lock_table三张表并修改conf/file.conf中的store.modedb以及数据库连接信息。配置注册中心修改conf/registry.conf指定TC如何被客户端发现。常用Nacos。registry { type nacos nacos { application seata-server serverAddr 127.0.0.1:8848 group SEATA_GROUP namespace cluster default } }启动sh bin/seata-server.sh2. 业务服务集成Seata Client每个参与分布式事务的微服务都需要引入Seata Client。引入依赖在Spring Boot项目中加入seata-spring-boot-starter。配置在application.yml中配置Seata。seata: application-id: your-service-name tx-service-group: my_tx_group # 事务组需与TC配置对应 service: vgroup-mapping: my_tx_group: default # 映射到TC的集群名 registry: type: nacos nacos: server-addr: 127.0.0.1:8848 group: SEATA_GROUP config: type: nacos nacos: server-addr: 127.0.0.1:8848 group: SEATA_GROUP >Service public class OrderServiceImpl implements OrderService { GlobalTransactional(name createOrder, rollbackFor Exception.class) public Order createOrder(OrderDTO orderDTO) { // 1. 本地创建订单 orderMapper.insert(order); // 2. 远程调用库存服务扣减库存 storageFeignClient.deduct(orderDTO.getProductId(), orderDTO.getCount()); // 如果此处或后续逻辑抛出异常Seata会触发全局回滚 // 3. 其他业务... return order; } }库存服务方法只需在方法上添加Transactional本地事务和GlobalTransactional的传播属性即可通常不需要除非它自身也是全局事务入口。4.3 一个完整的“下单-扣库存”AT模式事务流程假设订单服务端口8080和库存服务端口8081都已集成Seata Client且TC已启动。用户请求下单进入OrderService.createOrder()方法。Seata拦截到GlobalTransactional注解向TCSeata Server发起全局事务的开启请求。TC生成一个全局唯一的XID如192.168.1.1:8091:123456789并返回给订单服务。这个XID会在整个调用链中传播。订单服务执行本地orderMapper.insert。Seata数据源代理会生成一个分支事务IDBranch ID。在执行INSERT前查询前置数据镜像此处无。执行INSERT。查询后置数据镜像新插入的行。将前后镜像、SQL类型等信息作为回滚日志插入到订单数据库的undo_log表中。提交订单服务的本地事务。订单服务通过Feign调用库存服务的deduct接口XID会通过请求头如Seata-Xid自动传递。库存服务收到请求执行业务逻辑stockMapper.deduct。Seata数据源代理同样会生成该服务下的分支事务ID。执行UPDATE前查询当前库存值Before Image。执行UPDATE扣减库存。执行后查询库存新值After Image。将回滚日志插入库存数据库的undo_log。提交库存服务的本地事务。如果所有步骤成功OrderService.createOrder()方法执行完毕。Seata Client会向TC汇报全局事务完成TC驱动第二阶段——异步删除订单和库存数据库中的undo_log记录。如果在步骤5扣减库存时失败如库存不足抛异常异常会传播回订单服务。被GlobalTransactional注解感知后订单服务会向TC汇报全局事务失败。TC会向所有已注册的分支事务订单分支、库存分支发起回滚请求。各服务收到回滚请求后根据XID查找本地的undo_log生成并执行反向SQL订单分支是DELETE库存分支是UPDATE还原库存完成数据回滚。整个过程中业务开发者只需关注业务代码和添加一个GlobalTransactional注解复杂的日志记录、事务协调、回滚操作都由Seata框架自动完成实现了对业务代码的低侵入。5. 分布式事务实践中的常见“坑”与应对策略理论很美好实践却总是磕磕绊绊。下面是我总结的几个高频问题及解决办法。5.1 幂等性问题请求重试的噩梦在分布式环境下网络超时、服务抖动可能导致调用方重试从而产生重复请求。如果服务接口不幂等就会导致数据错误如扣了两次库存。解决方案数据库唯一约束利用业务唯一键如“订单号商品ID”作为联合唯一索引重复插入会失败。状态机在业务数据中增加状态字段。只有处于特定状态如“待处理”的请求才被执行执行后更新状态。重复请求会因为状态不匹配而被忽略。Token机制调用方先向服务方申请一个全局唯一的Token。调用业务接口时携带此Token。服务方在Redis中检查setnx Token “processing”如果设置成功表示第一次请求则执行业务完成后将Token值改为“done”如果设置失败Token已存在则判断是“processing”还是“done”分别返回“处理中”或“已处理”结果。分布式锁对于更复杂的非幂等操作可以使用分布式锁如基于Redis确保同一业务键在同一时刻只有一个请求能进入核心逻辑。 提示幂等性设计应是消费端服务提供方的责任不能依赖调用方不重试。在MQ消费、RPC接口设计中必须首要考虑幂等。5.2 空回滚与业务悬挂这是TCC模式下的典型问题在Seata的TCC模式中也会遇到。空回滚Try阶段因网络超时未执行但TC收到了Try失败的报告触发了全局回滚从而调用了Cancel。此时Cancel需要处理“未执行Try却收到Cancel”的情况。业务悬挂Cancel比Try请求先到达网络拥堵导致。Cancel执行了空回滚之后Try请求才到达并执行预留的资源再也无法被Confirm或Cancel处理。解决方案在Try阶段将全局事务XID和分支事务ID关联的业务数据如冻结记录插入数据库。这是关键的一步。在Cancel阶段先检查是否存在对应的Try记录。如果不存在说明是空回滚则记录一条状态为“已空回滚”的日志并直接返回成功。在Try阶段同样先检查是否存在该XID的Cancel记录空回滚记录。如果存在则拒绝执行Try防止业务悬挂。5.3 数据不一致的监控与补偿即使采用了成熟的方案在极端情况下如长时间网络分区、多个节点同时故障仍可能出现数据不一致。因此必须建立监控和对账补偿机制。监控事务状态监控监控Seata TC中长时间未完成悬挂的全局事务。日志告警监控错误日志特别是事务回滚、重试失败的日志。业务指标监控监控关键业务数据如“已支付订单数”与“已扣库存数”的差值趋势。对账补偿离线对账每天定时跑对账任务核对不同系统间的核心数据如订单库的订单状态与库存库的库存流水。发现不一致记录生成差错单。实时核对在关键业务流程中在事务完成后发送一条核对消息到消息队列由一个独立的核对服务消费实时检查关联数据的一致性。补偿作业对于对账发现的差错根据业务规则设计自动或半自动的补偿脚本。例如发现订单成功但库存未扣可以尝试调用库存服务的补偿接口进行扣减或通知运营人员人工处理。实操心得分布式事务方案选型没有银弹。对于核心的、实时性要求高的资金交易可考虑TCC。对于绝大部分互联网业务场景基于消息队列的最终一致性方案是性价比最高的选择配合完善的监控和对账能解决99%的问题。而Seata AT模式则为希望以较低侵入性获得分布式事务能力的团队提供了一个很好的折中选择但在高性能场景下需要注意其全局锁可能带来的性能影响。最终理解业务容忍度能接受多久的不一致是做出正确技术选型的第一步。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
