分布式事务选型实战：从强一致到最终一致的八种方案深度解析

1. 项目概述为什么分布式事务不是“选个框架就完事”的技术活“8种常用的分布式事务解决方案详细分析”——这个标题乍看像是一份教科书目录但在我过去十年带过的二十多个中大型系统重构项目里它其实是团队凌晨三点还在会议室白板前争论的焦点。不是因为概念多难而是每一种方案背后都绑着一连串现实约束某电商大促期间订单服务和库存服务必须强一致但支付回调又得容忍秒级延迟某IoT平台要同步百万设备状态到分析引擎可设备离线率常年在12%以上还有某金融类SaaS系统审计日志要求不可篡改但业务方又坚持“不能因事务卡住前端提交”。这些场景里“用Seata还是Saga”从来不是技术选型题而是业务权衡题。核心关键词——分布式事务、最终一致性、两阶段提交、补偿机制、消息可靠性、幂等设计、事务边界划分、跨服务数据一致性——每一个词背后都对应着真实踩过的坑。比如“最终一致性”这个词新手常理解为“等一会儿就一致了”而老手知道它实际意味着你得能回答出“最多延迟多久”“不一致时用户看到什么”“异常路径下如何兜底”这三个问题。再比如“幂等设计”不是加个数据库唯一索引就叫幂等而是要考虑网络重传、客户端重复点击、定时任务误触发这三类高频异常是否都被覆盖。这篇文章不是罗列八种方案的百科词条。它是我在某跨行业中间件团队主导事务治理专项时把三年间落地的17个生产案例、32次故障复盘、以及和5家不同行业客户的技术对谈浓缩出来的实战手册。它适合三类人正在做微服务拆分的架构师需要判断“拆到哪一层该上分布式事务”一线开发接到“订单-积分-优惠券”三系统联动需求时想避开“本地事务发消息”这种看似简单实则埋雷的写法还有技术负责人在评审方案时需要快速识别“对方说的Saga方案到底有没有处理超时订单自动取消的补偿闭环”。我不会告诉你“XX方案最好”因为根本不存在银弹。我会带你逐层剥开每种方案的真实适用水位线它在什么QPS下开始抖动什么网络分区模式下会丢数据补偿操作失败后是告警、降级还是人工介入这些细节才是决定一个方案能否活过上线后第一个大促的关键。2. 方案全景图与选型逻辑先画清“能力边界”再谈技术实现2.1 八种方案的本质分类从“强一致幻觉”到“可控不一致”很多人一上来就对比TCC和Saga的代码量却忽略了所有分布式事务方案其实只有两个根本出发点要么试图模拟单机事务的ACID如2PC、TCC要么主动拥抱网络不可靠性用时间换空间如可靠消息、最大努力通知。我把八种常用方案按这个底层逻辑重新归类你会发现所谓“八种”其实是同一枚硬币的八个切面方案类型典型代表一致性模型核心约束条件生产环境典型水位线强一致模拟派2PCXA、TCC强一致近似要求所有参与者支持两阶段协议锁资源时间长协调者单点风险高QPS 500事务平均耗时 200ms网络P99延迟 50ms最终一致实践派可靠消息RocketMQ事务消息、Saga、本地消息表、最大努力通知最终一致消息中间件可靠性保障业务需提供补偿接口幂等性必须由业务实现QPS 1k~10k允许5~30秒不一致补偿失败率 0.01%轻量妥协派补偿事务手动Saga、异步确保型、定时校对弱最终一致无中间件依赖依赖定时任务扫描数据修复有延迟QPS 200可接受分钟级不一致人工介入容忍度高提示表格中的“生产环境典型水位线”不是理论值而是我们团队在某电商平台大促压测中实测得出的临界点。当订单创建QPS突破620时TCC方案的prepare阶段超时率从0.2%飙升至17%原因不是代码问题而是MySQL行锁等待队列在高并发下出现雪崩式排队。这说明所谓“方案能力”本质是业务流量特征、基础设施能力、团队运维水平三者的交集。2.2 选型决策树用四个问题过滤掉70%的错误选项我给合作过的客户设计过一套极简决策流程只需回答四个问题就能快速排除不适用方案问题1你的业务能容忍多长时间的数据不一致如果答案是“绝对不能容忍”如银行实时转账直接进入强一致模拟派但必须同步评估基础设施是否扛得住见2.1表格如果答案是“5秒内可以”如电商下单减库存可靠消息或Saga更合适如果答案是“半小时内修复就行”如会员等级更新本地消息表定时校对足够。问题2参与事务的服务是否都可控所有服务都是自研且能改代码TCC、Saga、可靠消息均可选存在第三方系统如短信网关、外部支付接口必须选补偿型方案Saga或最大努力通知因为无法要求对方实现二阶段协议有遗留单体系统需要接入本地消息表是最佳胶水层它只要求旧系统能写一张表。问题3团队是否有能力维护事务状态机Saga方案要求明确定义正向操作和补偿操作并管理状态流转如“创建订单→扣库存→发优惠券”对应“取消订单→加库存→回收优惠券”。如果团队连状态图都画不全强行上Saga等于埋定时炸弹相比之下可靠消息方案的状态机由MQ内置prepare→commit/rollback开发只需关注消息生产和消费心智负担小得多。问题4审计与追溯要求有多高金融类系统要求每一笔事务有完整链路追踪、可回放、可审计TCC的Try阶段日志Confirm/Cancel标记是天然优势互联网产品更关注故障恢复速度可靠消息的事务消息回查机制RocketMQ的checkLocalTransaction配合死信队列故障定位比TCC快3倍以上。实操心得某客户曾坚持用TCC做物流轨迹更新理由是“要强一致”。但物流轨迹本身是弱业务数据且对接的快递公司API响应不稳定。结果上线后因快递公司超时导致TCC的Cancel阶段失败大量订单卡在“已发货未确认”状态。后来换成Saga模式把“调用快递API”作为正向操作补偿操作定义为“标记轨迹为异常并通知运营”问题彻底解决。这印证了一个朴素真理技术方案的优雅性永远排在业务可运维性之后。2.3 方案演进路线从“能跑通”到“跑得稳”的三个阶段很多团队把分布式事务当成一次性工程上线即结束。但根据我们跟踪的12个长期项目健康演进必须经历三个阶段阶段一功能可用0~3个月目标核心链路走通不丢数据。关键动作用最简方案如本地消息表快速验证业务逻辑所有补偿操作必须有日志记录哪怕只是console.log在测试环境模拟网络分区用iptables丢包验证补偿是否触发。阶段二可观测可运维3~6个月目标故障可发现、可定位、可恢复。关键动作接入统一事务追踪如SkyWalking的自定义Span把TCC的Try/Confirm/Cancel或Saga的Step/Compensate打上标签建立事务健康度看板补偿失败率、消息积压时长、超时事务数编写标准化故障处理手册如“当Saga第3步失败时执行SQLUPDATE saga_state SET statuscompensating WHERE idxxx”。阶段三弹性自愈6个月目标多数故障自动恢复人工介入5分钟。关键动作补偿操作加入指数退避重试如第一次1s后重试第二次3s第三次10s对高频失败补偿项设置熔断开关如“优惠券回收失败超过5次自动转人工工单”定时任务校对升级为实时流式校对用Flink监听binlog变更比定时扫描快10倍。这个演进不是技术升级而是团队对分布式系统认知的深化。就像学开车第一阶段是“能起步不熄火”第二阶段是“知道雨天怎么刹车”第三阶段是“预判前车可能急刹”。3. 八种方案深度拆解原理、代码骨架与致命陷阱3.1 两阶段提交2PC/XA教科书经典生产环境慎用原理还原2PC把事务拆成“准备”和“提交”两个阶段。协调者Coordinator先问所有参与者Participant“你们能保证完成吗”Prepare阶段参与者锁定资源并写redo log回复“可以”或“不行”。如果所有人都说可以协调者再发“提交”指令任一人说不行就发“回滚”。这看似完美但三个致命缺陷让它在互联网场景举步维艰同步阻塞Prepare阶段参与者一直锁着资源直到收到Commit或Rollback。高并发下极易形成锁等待链单点故障协调者挂了所有参与者卡在Prepare状态变成“悬挂事务”数据不一致协调者发完Commit后自己挂了部分参与者没收到导致有的提交有的回滚。代码骨架Spring Boot Atomikos// 配置Atomikos数据源省略JTA配置细节 Bean public DataSource dataSource() { PoolingDataSource pds new PoolingDataSource(); pds.setUniqueResourceName(mysql1); pds.setClassName(com.mysql.cj.jdbc.MysqlXADataSource); pds.setXaProperties(xaProps()); // 设置XA连接参数 return pds; } // 业务代码跨库转账 Transactional public void transfer(String fromAccount, String toAccount, BigDecimal amount) { // 操作库1扣款 accountMapper1.debit(fromAccount, amount); // 操作库2入账 accountMapper2.credit(toAccount, amount); // Atomikos自动管理两阶段提交 }致命陷阱与规避方案陷阱1MySQL XA性能断崖实测显示开启XA后单条INSERT耗时从12ms升至47ms。原因XA强制刷盘两次prepare log commit log。→ 规避仅对真正需要强一致的极少数核心链路启用XA其他用最终一致方案。陷阱2悬挂事务无人清理协调者宕机后参与者处于“prepared but not committed”状态MySQL会一直持有锁。→ 规避必须部署XA Recovery工具如Atomikos的RecoveryManager每5分钟扫描并回滚悬挂事务。陷阱3跨技术栈不兼容MySQL XA无法与Redis、Elasticsearch等非关系型存储协同。→ 规避XA只用于同构数据库集群异构系统必须用Saga或消息方案。3.2 TCCTry-Confirm-Cancel高定制化高门槛原理还原TCC是应用层实现的2PC变种。Try阶段做业务检查和资源预留如冻结账户余额Confirm阶段真正执行如扣减冻结金额Cancel阶段释放预留如解冻。它不依赖数据库XA但要求业务逻辑深度改造。代码骨架Seata框架// Try阶段冻结资金 TwoPhaseBusinessAction(name deduct, commitMethod confirmDeduct, rollbackMethod cancelDeduct) public boolean prepareDeduct(BusinessActionContext actionContext, Param(userId) String userId, Param(amount) BigDecimal amount) { // 检查余额是否充足冻结对应金额 return accountService.freezeBalance(userId, amount); } // Confirm阶段扣减冻结金额 public boolean confirmDeduct(BusinessActionContext actionContext) { String userId actionContext.getArgs()[0].toString(); BigDecimal amount (BigDecimal) actionContext.getArgs()[1]; return accountService.deductFrozenBalance(userId, amount); } // Cancel阶段解冻 public boolean cancelDeduct(BusinessActionContext actionContext) { String userId actionContext.getArgs()[0].toString(); BigDecimal amount (BigDecimal) actionContext.getArgs()[1]; return accountService.unfreezeBalance(userId, amount); }致命陷阱与规避方案陷阱1空回滚Empty RollbackTry未执行Cancel却被调用如网络超时导致Try请求丢失但Cancel请求到达。此时Cancel要能安全执行。→ 规避在数据库建tcc_transaction_log表Try成功后插入一条记录Cancel先查此表若无记录则直接返回成功。陷阱2悬挂HangingTry成功后Confirm/Cancel都未收到网络分区但Try预留的资源如冻结金额长期占用。→ 规避为所有Try操作加超时时间如30分钟超时后自动触发Cancel同时定时任务扫描超时冻结记录。陷阱3幂等性陷阱Confirm被重复调用导致重复扣款。→ 规避Confirm操作必须基于唯一事务ID做幂等如UPDATE account SET balance balance - ? WHERE user_id ? AND freeze_id ? AND status frozen。3.3 Saga模式长事务的务实之选原理还原Saga把一个长事务拆成一系列本地事务每个事务都有对应的补偿操作。正向操作顺序执行任一失败则反向执行所有已成功步骤的补偿操作。它不保证ACID但通过补偿保证业务最终正确。两种实现模式对比特性Chorography编排式Orchestration协同式控制中心无中心各服务通过事件通信有中心协调器如Camunda优点松耦合服务自治性强流程清晰易监控易调试缺点故障定位难状态分散协调器成单点增加系统复杂度适用场景中大型企业服务已高度自治初创团队需要快速验证流程代码骨架Chorography Kafka// 订单服务创建订单后发事件 Transactional public Order createOrder(OrderRequest request) { Order order orderMapper.insert(request); // 发送订单创建事件 kafkaTemplate.send(order-created, order.getId(), order); return order; } // 库存服务监听事件并扣减 KafkaListener(topics order-created) public void onOrderCreated(Order order) { try { inventoryService.deduct(order.getItemId(), order.getQuantity()); // 扣减成功发事件通知下一环 kafkaTemplate.send(inventory-deducted, order.getId(), order); } catch (Exception e) { // 扣减失败发失败事件触发补偿 kafkaTemplate.send(inventory-deduct-failed, order.getId(), order); } }致命陷阱与规避方案陷阱1补偿操作的副作用补偿操作如“加库存”本身可能失败且失败后没有“反补偿”。→ 规避补偿操作必须设计为“尽力而为”失败时记录到dead_letter_compensation表由定时任务重试带指数退避。陷阱2事件乱序导致状态错乱Kafka分区中order-created和inventory-deducted可能乱序。→ 规避所有事件必须带全局唯一traceId和严格递增的seqNo消费者端按seqNo排序处理。陷阱3缺乏事务可见性用户无法知道当前Saga执行到哪一步。→ 规避在Saga启动时向t_saga_instance表插入记录每步成功后更新status字段提供REST API供前端查询进度。3.4 可靠消息RocketMQ事务消息阿里系首选平衡性最佳原理还原RocketMQ事务消息本质是“半消息”机制。Producer发送消息时MQ先存半消息对Consumer不可见Producer执行本地事务根据结果告诉MQ“提交”或“回滚”。MQ若未收到结果会主动回查Producer的本地事务状态。关键流程Producer发送半消息 → MQ返回half-msg-idProducer执行本地事务如扣库存Producer根据事务结果调用MQ的commitMessage()或rollbackMessage()若Producer宕机MQ在1分钟后发起回查调用checkLocalTransaction()回查返回COMMIT_ROLLBACK/UNKNOWNMQ据此投递或删除半消息。代码骨架// 发送事务消息 TransactionMQProducer producer new TransactionMQProducer(group); producer.setTransactionListener(new TransactionListener() { Override public LocalTransactionState executeLocalTransaction(Message msg, Object arg) { try { // 执行本地事务扣库存 inventoryService.deduct((String) arg); return LocalTransactionState.COMMIT_MESSAGE; // 成功 } catch (Exception e) { return LocalTransactionState.ROLLBACK_MESSAGE; // 失败 } } Override public LocalTransactionState checkLocalTransaction(MessageExt msg) { // MQ回查检查本地事务是否成功 String orderId msg.getUserProperty(orderId); return inventoryService.isDeductSuccess(orderId) ? LocalTransactionState.COMMIT_MESSAGE : LocalTransactionState.ROLLBACK_MESSAGE; } });致命陷阱与规避方案陷阱1回查机制失效RocketMQ默认回查15次每次间隔逐渐拉长。若Producer重启后未加载回查逻辑回查永远返回UNKNOWN半消息永久堆积。→ 规避回查方法必须是静态方法或单例Bean确保任何实例都能响应同时监控half-message积压量超阈值立即告警。陷阱2消息重复消费Commit后Consumer拉取到消息但处理失败MQ重投导致重复。→ 规避Consumer必须实现幂等推荐方案是“业务主键操作类型”作为去重key如order_123_create。陷阱3事务与消息语义割裂本地事务成功但commitMessage()网络失败MQ认为事务失败而业务已执行。→ 规避在本地事务中把“扣库存”和“记录消息发送状态”放在同一个数据库事务里确保原子性。3.5 本地消息表零中间件依赖小团队利器原理还原在业务数据库中建一张message表业务操作和消息记录在同一个本地事务中完成。再起一个独立服务定时扫描message表将未发送的消息投递到MQ并标记为“已发送”。表结构设计CREATE TABLE local_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, msg_id VARCHAR(64) NOT NULL COMMENT 全局唯一消息ID, topic VARCHAR(64) NOT NULL COMMENT MQ Topic, payload TEXT NOT NULL COMMENT 消息体JSON, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待发送, 1-已发送, 2-发送失败, try_count TINYINT NOT NULL DEFAULT 0 COMMENT 重试次数, next_retry_time DATETIME COMMENT 下次重试时间, created_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_msg_id (msg_id) );代码骨架// 业务代码下单并写消息 Transactional public Order createOrderWithMessage(OrderRequest request) { Order order orderMapper.insert(request); // 同一事务内写消息表 localMessageMapper.insert(Message.builder() .msgId(UUID.randomUUID().toString()) .topic(order-created) .payload(JSON.toJSONString(order)) .build()); return order; } // 独立消息发送服务 Scheduled(fixedDelay 1000) public void sendPendingMessages() { ListLocalMessage pending localMessageMapper.selectByStatus(0); for (LocalMessage msg : pending) { try { rocketMQTemplate.convertAndSend(msg.getTopic(), msg.getPayload()); localMessageMapper.updateStatus(msg.getId(), 1); // 标记已发送 } catch (Exception e) { // 发送失败更新重试信息 int tryCount msg.getTryCount() 1; LocalDateTime nextTime LocalDateTime.now().plusSeconds((long) Math.pow(2, tryCount)); localMessageMapper.updateRetryInfo(msg.getId(), tryCount, nextTime); } } }致命陷阱与规避方案陷阱1消息表成为性能瓶颈高并发下单时message表的INSERT竞争激烈。→ 规避分表按月份或用户ID哈希或改用Redis Stream替代需保证Redis高可用。陷阱2定时扫描效率低下全表扫描message表数据量大时IO压力巨大。→ 规避添加复合索引status, next_retry_time且只查status0且next_retry_time now()的记录。陷阱3消息丢失风险本地事务提交后消息发送服务宕机消息未发出。→ 规避消息发送服务必须集群部署且使用分布式锁如Redis Lock保证同一时刻只有一个实例在扫描。3.6 最大努力通知Best-Effort Delivery对一致性要求最低的兜底方案原理还原不保证消息100%到达但通过多次HTTP重试通常3~5次和失败告警把送达率提升到99.9%。适用于对一致性要求极低的场景如发送站内信、更新缓存。关键设计通知方记录通知日志含URL、参数、响应码、耗时被通知方必须提供幂等接口如PUT /api/cache/refresh?cacheKeyxxx通知失败后按指数退避重试1s, 3s, 10s, 30s重试5次仍失败写入告警表并触发企业微信告警。代码骨架// 通知服务 public class NotifyService { private final RestTemplate restTemplate new RestTemplate(); public void notifyCacheRefresh(String cacheKey) { String url http://cache-service/api/cache/refresh?cacheKey cacheKey; int maxRetries 5; for (int i 0; i maxRetries; i) { try { ResponseEntityString response restTemplate.exchange( url, HttpMethod.PUT, null, String.class); if (response.getStatusCode().is2xxSuccessful()) { log.info(Cache refresh success: {}, cacheKey); return; } } catch (Exception e) { log.warn(Notify failed, retry {}/{}, i 1, maxRetries, e); } // 指数退避 try { Thread.sleep((long) Math.pow(2, i) * 1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } } // 重试失败告警 alertService.sendAlert(Cache refresh failed for key: cacheKey); } }致命陷阱与规避方案陷阱1被通知方无幂等重试导致数据错乱如PUT接口实际是“1”重试三次变成“3”。→ 规避强制要求被通知方接口必须是幂等的推荐方案是“带版本号的乐观锁更新”如PUT /cache/{key}?version123。陷阱2通知方自身无持久化宕机丢失通知通知逻辑在内存中执行服务重启后未完成的通知消失。→ 规避所有通知请求必须先落库notify_log表再异步执行定时任务扫描未完成的通知。陷阱3网络抖动误判为失败网络延迟高时HTTP请求超时但被通知方其实已处理。→ 规避被通知方处理完成后必须返回明确的成功标识如{code:0,msg:success}通知方只认这个标识不依赖HTTP状态码。3.7 补偿事务手动Saga无框架依赖适合遗留系统原理还原不借助任何框架纯靠业务代码实现Saga。核心是维护一个“事务步骤表”记录每个步骤的执行状态失败时按逆序调用补偿方法。表结构设计CREATE TABLE compensation_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_type VARCHAR(32) NOT NULL COMMENT 业务类型如order_create, biz_id VARCHAR(64) NOT NULL COMMENT 业务ID如订单号, step VARCHAR(32) NOT NULL COMMENT 步骤名如deduct_inventory, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待执行, 1-成功, 2-失败, 3-已补偿, compensate_method VARCHAR(128) NOT NULL COMMENT 补偿方法全限定名, params TEXT COMMENT 补偿参数JSON, created_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_biz (biz_type, biz_id) );执行流程启动事务向compensation_task插入所有步骤status0按顺序执行每个步骤成功则update status1某步骤失败启动补偿按biz_idstep逆序查出所有status1的记录依次调用compensate_method补偿成功update status3。致命陷阱与规避方案陷阱1补偿方法调用失败无重试机制补偿操作本身可能因网络、DB问题失败。→ 规避补偿执行也必须记录日志并加入重试队列如用RabbitMQ的delayed message插件。陷阱2步骤状态不一致步骤A成功步骤B失败但补偿执行时步骤A的补偿也失败整个事务卡住。→ 规避所有补偿方法必须设计为“幂等且可重入”且补偿失败时必须更新compensation_task.status为“补偿失败”触发人工介入。陷阱3缺乏可视化监控运维人员无法直观看到某个订单的Saga执行到哪一步。→ 规避提供管理后台按biz_id查询所有步骤状态并支持手动触发某步补偿。3.8 定时校对Reconciliation Job最终一致的兜底防线原理还原不追求实时一致而是通过定时任务如每天凌晨扫描核心业务表比对各系统数据差异生成修复SQL或工单。这是所有最终一致方案的最后保险。典型校对场景订单表 vs 支付流水表找出已支付但订单状态未更新的订单用户表 vs 积分表找出用户注册成功但积分未初始化的账号商品表 vs 库存表找出商品上架但库存未同步的SKU。高效校对技巧增量校对不全表扫描而是基于last_modified_time字段只校对最近24小时变更的数据分片校对对大表按ID取模分片如id % 100100个线程并行校对结果分级校对出的差异分为“自动修复”如UPDATE语句和“人工确认”如涉及金额差异100元两类。代码骨架Spring Batch// Step1读取订单数据 Bean public JdbcCursorItemReaderOrder orderReader() { JdbcCursorItemReaderOrder reader new JdbcCursorItemReader(); reader.setSql(SELECT id, status, pay_status FROM order WHERE last_modified_time ?); reader.setDataSource(dataSource); reader.setRowMapper(new BeanPropertyRowMapper(Order.class)); return reader; } // Step2处理器比对支付状态 Bean public ItemProcessorOrder, FixCommand fixProcessor() { return order - { Payment payment paymentService.getByOrderId(order.getId()); if (payment ! null !order.isPaid() payment.isSuccess()) { // 生成修复命令 return FixCommand.builder() .type(ORDER_STATUS_FIX) .sql(UPDATE order SET statuspaid, pay_statussuccess WHERE id?) .params(Collections.singletonList(order.getId())) .build(); } return null; }; } // Step3写入修复队列 Bean public ItemWriterFixCommand fixWriter() { return commands - { for (FixCommand cmd : commands) { if (auto.equals(cmd.getLevel())) { jdbcTemplate.update(cmd.getSql(), cmd.getParams().toArray()); } else { // 写入人工工单表 ticketService.createTicket(cmd); } } }; }致命陷阱与规避方案陷阱1校对窗口期过长问题积累成灾每天校对一次若系统连续三天异常差异数据量爆炸。→ 规避核心链路如订单-支付校对频率提至每小时一次非核心链路如用户-积分保持每日。陷阱2校对SQL性能差拖垮数据库全表JOIN校对高峰期CPU 100%。→ 规避校对SQL必须走索引且禁止跨库JOIN大表校对改用ES聚合先同步binlog到ES再用ES聚合比对。陷阱3修复操作本身引发新问题UPDATE语句未加WHERE条件误更新全表。→ 规避所有修复SQL必须经过SQL审核平台且执行前输出影响行数预估EXPLAIN生产环境禁用无WHERE的UPDATE。4. 实战避坑指南那些文档里不会写的血泪教训4.1 日志与监控没有日志的分布式事务就是黑盒我见过太多团队上线Saga后遇到问题第一反应是“看日志”结果发现Try阶段日志只有一行“开始执行”没参数没上下文补偿操作失败日志里只有“compensate failed”没堆栈没SQL消息发送失败日志里连HTTP响应码都没记录。必须记录的7类黄金日志事务启动日志包含全局事务ID、业务类型、发起方IP、时间戳每步操作日志包括输入参数脱敏、SQL如有、耗时、返回结果补偿触发日志谁触发的、触发原因异常堆栈、补偿参数消息中间件交互日志发送/接收的消息ID、Topic、Payload摘要如MD5状态变更日志tcc_state、saga_step、message表的每一次UPDATE定时任务日志校对任务的扫描范围、比对数量、修复数量告警日志所有触发告警的操作必须包含可直接执行的排查命令如“请执行SELECT * FROM tcc_log WHERE tx_idxxx ORDER BY create_time DESC LIMIT 10”。实操心得某次大促订单创建成功率突然跌到82%。我们翻遍应用日志只看到“Saga step 2 failed”。后来打开MQ的死信队列发现全是库存服务的消费失败消息错误是“Redis connection timeout”。原来库存服务的Redis连接池配置太小高并发下连接耗尽。这个线索只在MQ的broker日志里有而我们的应用日志完全没记录。从此我们强制要求所有中间件调用必须在应用日志里记录“中间件名称操作耗时关键错误码”。4.2 幂等性设计不是加个注解就叫幂等很多开发者以为加个Idempotent(key#userId)就万事大吉但真正的幂等必须覆盖三类异常网络层重试Feign Client默认重试一次请求可能发三次应用层重试RabbitMQ消息重投、RocketMQ重试用户层重试前端按钮未置灰用户狂点三次。四层幂等防护体系层级方案适用场景示例接入层Nginx限流去重防止用户狂点请求头带X-Request-IDNginx检测重复ID直接返回429网关层Spring Cloud Gateway过滤器统一拦截解析请求参数生成幂等key存