★ FEATURED ARTICLE 1. 项目概述为什么“分布式事务面试题”不是一道题而是一张能力验证网“分布式事务面试题”这六个字最近在技术招聘场景里出现的频率已经高到让不少面试官自己都开始怀疑——我们到底是在招后端工程师还是在筛选分布式系统架构师我带过十几轮校招和社招面试也作为候选人被问过不下二十次“如何保证分布式事务一致性”每次听到这个问题我心里都先默念一遍千万别只答“Seata”“TCC”“Saga”更别一上来就画两段伪代码。因为真正拉开差距的从来不是你背了多少名词而是你能不能在3分钟内把一个业务场景、一个数据异常、一次服务拆分、一种网络分区全部串成一条逻辑链再反向推导出事务方案的取舍依据。这根本不是考概念复述而是一场系统性工程思维的压力测试。它背后藏着至少五层真实需求第一层是基础认知——你是否理解本地事务ACID在分布式环境下的天然失效第二层是场景识别能力——订单创建库存扣减积分发放这三个操作到底该用强一致还是最终一致第三层是技术权衡意识——为什么某电商核心下单链路宁可牺牲100ms延迟也要上2PC而另一家内容平台却敢用消息表定时补偿第四层是落地细节敏感度——TCC的Confirm接口幂等怎么防Saga的补偿动作失败后如何兜底第五层也是最容易被忽略的一层你有没有在真实压测中见过XA协议下数据库连接池耗尽的雪崩现场有没有在凌晨三点排查过RocketMQ事务消息回查超时导致的重复消费所以“分布式事务面试题”本质上是一张能力验证网网住的是你对数据可靠性边界、服务治理成本、业务容忍阈值、基础设施成熟度这四者的综合判断力。它不挑语言Java/Go/Python都一样不卡框架Spring Cloud/Dubbo/K8s原生都适用但极其挑剔你是否真的把“事务”从教科书里搬进了生产环境。如果你还停留在“CAP定理三选二”的口头禅阶段那建议先去线上查三天慢SQL日志——真正的分布式事务问题90%都藏在单机事务没写好、索引没建对、连接没释放这些“基础漏洞”里。所谓高阶问题往往始于低阶失守。2. 内容整体设计与思路拆解从“答题模板”到“决策树模型”的范式迁移很多候选人面对“分布式事务怎么实现”这个问题会本能地启动一套标准应答流程先列四种模式2PC、TCC、Saga、本地消息表再各自优缺点对比最后补一句“根据业务场景选择”。这套话术听起来很完整但在我作为面试官的实操经验里它暴露的恰恰是缺乏真实系统演进视角。因为任何一家公司引入分布式事务方案从来不是从零开始做学术选型而是被业务倒逼着在现有技术栈、团队能力、运维水位、故障历史的多重约束下一步步踩坑、试错、收敛出来的。所以我把整个面试考察逻辑重构为一棵“决策树模型”它的根节点不是“用什么技术”而是“业务能承受什么代价”。2.1 决策树的第一叉业务一致性要求是刚性还是弹性这是所有后续判断的起点。我常举一个例子用户支付成功后订单状态必须立刻变为“已支付”否则前端刷新页面看到“待支付”用户会疯狂点击重试引发资损。这个场景下“刚性一致”就是生死线——哪怕多花50ms、多加两次网络往返、多维护一个协调者节点也必须保证。此时2PC或强一致性TCC就是合理选项。但反过来如果是一个“用户浏览商品后推荐系统异步更新用户画像”的场景画像晚同步10秒完全不影响主流程那强行上2PC就是资源浪费。这里的关键不是背熟“强一致/最终一致”的定义而是你能否快速识别出业务SLA中的一致性时间窗口Consistency Time Window。比如某金融类App规定“交易流水与账户余额差异不得超过3秒”这个3秒就是硬指标它直接决定了你能否接受Saga模式中补偿动作可能耗时5秒的风险。提示面试中如果候选人脱口而出“我们用Saga”我会立刻追问“你们的业务允许最大最终一致时间是多少这个数值是怎么测出来的上线后有没有出现过超过该阈值的case”——90%的人答不上来因为他们没参与过真实的数据一致性基线测量。2.2 决策树的第二叉当前技术栈与团队能力是否匹配方案复杂度技术选型永远不是“理论上最优”而是“当前团队能稳稳托住”。我见过最典型的反面案例某创业公司用Go重构订单系统团队5人其中3人Go经验不足半年却在架构评审会上拍板“全量接入Seata AT模式”。结果上线两周光是排查AT模式下undo_log表膨胀导致的磁盘告警就占用了60%的运维时间。后来我们回溯发现他们连MySQL binlog格式配置、redo log刷盘策略这些基础项都没吃透就急着上分布式事务中间件。所以我在决策树里强制加入“团队能力雷达图”横轴是数据库MySQL/Oracle/PostgreSQL、中间件RocketMQ/Kafka/Pulsar、语言生态Spring AOP/Go middleware/Python decorator三个维度纵轴是团队对该技术的掌握深度L1-能跑通DemoL2-能调优参数L3-能看懂源码修复Bug。只有当三个维度都达到L2以上才考虑引入需要深度集成的方案如Seata AT或TCC。2.3 决策树的第三叉基础设施的可观测性与容灾能力是否兜底分布式事务最大的陷阱是把“方案能跑通”等同于“线上能稳住”。但真实世界里网络抖动、磁盘满、GC停顿、DNS解析失败这些“灰色故障”会让任何精妙的协议瞬间失效。所以决策树最后一层必须评估你的监控告警体系是否覆盖了关键断点。比如用消息队列做事务解耦你是否监控了生产者发送消息的成功率与耗时P99消息队列自身的堆积量与消费延迟消费者处理消息的失败率及重试次数分布补偿任务的执行成功率与超时率没有这些指标所谓的“最终一致性”就是一句空话。我曾协助某物流平台排查过一个持续数小时的运单状态不一致问题最终定位到是Kafka消费者组rebalance期间有少量消息被重复消费而补偿逻辑没做幂等导致运费被多扣。这个故障的根本原因不是Saga模式本身有问题而是他们没在rebalance事件发生时触发告警失去了黄金10分钟的干预窗口。3. 核心细节解析与实操要点穿透协议表象直击落地痛点当候选人说出“我们用TCC模式”时我接下来的问题一定不是“TCC是什么”而是“你们的Try阶段锁的是什么粒度Confirm失败后Cancel动作的超时时间设为多少Cancel失败又怎么兜底”——因为所有分布式事务方案的魔鬼都藏在这些具体参数与异常分支里。下面我以四个主流方案为切口逐个拆解那些文档里绝不会写的实操细节。3.1 2PC不是“过时”而是“用不起”很多人认为2PC已被淘汰其实不然。在银行核心账务、证券清算这类对数据绝对一致性要求极高的场景2PC仍是不可替代的。但它真正的门槛从来不是协议复杂而是协调者单点风险与参与者资源锁定成本。协调者高可用怎么做简单的主备切换不行。因为协调者宕机时参与者可能处于“预提交”状态此时新主协调者无法判断该全局事务是该Commit还是Abort。工业级方案必须引入协调者状态持久化跨节点共识。比如某支付平台用Etcd存储每个2PC事务的状态快照包括参与者列表、当前阶段、超时时间并用Raft协议保证多个协调者节点间状态同步。这样即使主协调者挂掉从节点也能基于Etcd中最新快照继续推进。参与者资源锁定时间怎么控这是2PC性能瓶颈的核心。传统做法是Try阶段就锁库存直到DoCommit才释放高峰期锁表导致大量请求排队。我们优化后的实践是Try阶段只做轻量级预占如Redis原子计数器扣减真正的数据库行锁延迟到DoCommit阶段才加。这样把锁持有时间从秒级压缩到毫秒级QPS提升3倍以上。当然这要求Cancel阶段必须能回滚Redis操作且要处理Redis与DB双写不一致的极端情况我们用定时任务扫描Redis中过期未确认的预占记录主动触发Cancel。注意2PC的超时时间设置是门玄学。设太短如5秒网络抖动就会误判为失败引发大量无效回滚设太长如5分钟资源长期被锁系统吞吐暴跌。我们的经验值是取“平均网络RTT 平均DB事务耗时”的3倍再向上取整到10秒档位。比如RTT 20msDB事务平均80ms则超时设为300ms × 3 900ms → 取整为1000ms。3.2 TCC三分靠协议七分靠业务改造TCCTry-Confirm-Cancel常被夸为“高性能柔性事务”但真实落地时80%的失败源于业务方对“Try阶段”的误解。很多人以为Try就是“检查库存是否充足”其实Try的本质是预留业务资源并确保该预留可被Confirm或Cancel无损解除。Try阶段的资源预留必须是“可逆”的举个反例某电商在Try阶段直接UPDATE库存表SET stock stock - 1 WHERE sku_id ? AND stock 0这看似合理但一旦Confirm失败需要Cancel你得再UPDATE回去SET stock stock 1。问题来了如果Cancel执行时该SKU被其他订单抢购stock已归零这次1就会导致超卖正确做法是Try阶段新建一张reserve_stock表记录sku_id, user_id, reserve_amount, expire_timeConfirm时才真正扣减主库存Cancel时直接DELETE这条预留记录。这样Cancel永远是幂等的。Confirm/Cancle的幂等性不是可选项是必选项网络重试会让Confirm或Cancel被多次调用。我们强制所有Confirm/Cancle接口接收一个全局事务IDXID和分支事务IDBranchID并在DB中建唯一索引(xid, branch_id, action_type)action_type为confirm或cancel。每次执行前先INSERT这条记录利用数据库唯一键冲突机制天然实现幂等。比在代码里查表判断快一个数量级且100%可靠。3.3 Saga编排式与协同式的血泪抉择Saga模式分两种实现编排式Choreography和协同式Orchestration。前者靠事件驱动各服务监听彼此发布的事件后者由一个中央协调器Saga Orchestrator控制流程。表面看编排式更“松耦合”但实际生产中90%的团队最终都转向协同式原因很现实编排式调试成本高到无法接受一个Saga流程涉及5个服务每个服务发布3种事件总共15个事件类型。当某个环节失败你需要在15个服务的日志里按时间戳拼凑出完整的事件流再判断是哪个事件丢失或重复。我们做过实验同样一个补偿失败问题编排式平均定位时间是47分钟协同式只要8分钟——因为所有日志都集中在Orchestrator的单个日志文件里且每步执行都有明确状态标记started/failed/compensated。协同式补偿失败的兜底必须前置设计协同式最大的风险是Orchestrator自身故障。我们的方案是Orchestrator每次推进Saga步骤前先将下一步指令写入DB状态为pending再执行该步骤执行成功后再UPDATE状态为done。这样即使Orchestrator进程崩溃重启后只需扫描所有pending状态的指令重新投递即可。但Compensate步骤失败怎么办我们在Orchestrator中内置一个“人工干预通道”当某个Compensate连续失败3次自动触发企业微信告警并生成一条待办任务指派给对应服务的负责人要求其手动执行补偿SQL。这个设计看似“不优雅”但在金融级系统里它比任何自动重试都可靠。3.4 本地消息表最土也最稳本地消息表Local Message Table常被贬为“过时方案”但它在中小团队、遗留系统改造、强依赖关系简单等场景下依然是性价比最高的选择。它的核心思想是把消息发送和本地事务绑定在同一DB事务中利用DB的ACID保证消息不丢。消息表结构设计决定成败常见错误是只建一张message表字段为id, content, status, create_time。这会导致两个问题一是status字段频繁UPDATE引发行锁竞争二是海量消息堆积时SELECT未处理消息的SQL会越来越慢。我们的优化是分表按业务域分order_msg,payment_msg,inventory_msg避免单表过大状态分离用status字段存当前状态sending/sent/failed另加next_retry_time字段存下次重试时间查询时WHEREnext_retry_time NOW()配合该字段的索引查询效率提升10倍冗余关键字段在消息表中冗余biz_id如order_id、biz_type方便按业务维度快速定位问题。死信处理不能只靠“重试”我们规定单条消息最多重试3次每次间隔指数增长1s, 3s, 9s。第3次失败后不再重试而是将消息转入dead_letter_queue表并触发告警。Dead Letter消息必须由专人处理处理方式只有两种要么人工核对业务状态后补发要么确认该消息已无业务意义执行DELETE。我们严禁“无限重试”因为那只会让下游服务雪崩。4. 实操过程与核心环节实现从零搭建一个可验证的Saga协同式事务Demo纸上谈兵终觉浅下面我带你用最简技术栈Spring Boot MySQL RocketMQ从零实现一个可运行、可调试、可压测的Saga协同式事务Demo。这个Demo模拟“用户下单→扣库存→发优惠券”三步流程重点展示Orchestrator如何控制状态流转、如何处理超时、如何触发补偿。所有代码均可直接复制运行参数已按生产经验调优。4.1 环境准备与依赖配置首先初始化一个Spring Boot 2.7.x项目JDK 11pom.xml关键依赖如下dependencies !-- Web基础 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MySQL驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- MyBatis -- dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.2.2/version /dependency !-- RocketMQ客户端 -- dependency groupIdorg.apache.rocketmq/groupId artifactIdrocketmq-spring-boot-starter/artifactId version2.2.3/version /dependency !-- Lombok简化代码 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies数据库建表语句MySQL 5.7-- Saga协调器状态表核心 CREATE TABLE saga_instance ( id varchar(64) NOT NULL COMMENT Saga全局事务ID, status tinyint NOT NULL DEFAULT 0 COMMENT 0started, 1completed, 2failed, 3compensating, 4compensated, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, last_update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, timeout_seconds int NOT NULL DEFAULT 300 COMMENT 全局超时时间单位秒, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENTSaga实例状态表; -- Saga步骤执行记录表 CREATE TABLE saga_step ( id bigint NOT NULL AUTO_INCREMENT, saga_id varchar(64) NOT NULL COMMENT 关联saga_instance.id, step_name varchar(64) NOT NULL COMMENT 步骤名称如order_create, status tinyint NOT NULL DEFAULT 0 COMMENT 0pending, 1executing, 2executed, 3failed, 4compensating, 5compensated, execute_time datetime NULL DEFAULT NULL COMMENT 执行开始时间, complete_time datetime NULL DEFAULT NULL COMMENT 执行完成时间, retry_count int NOT NULL DEFAULT 0 COMMENT 重试次数, max_retry int NOT NULL DEFAULT 3 COMMENT 最大重试次数, error_message text COMMENT 错误信息, PRIMARY KEY (id), KEY idx_saga_id (saga_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENTSaga步骤执行记录; -- 订单表业务表 CREATE TABLE order_info ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL UNIQUE, user_id bigint NOT NULL, amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0draft, 1created, 2paid, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 库存表业务表 CREATE TABLE inventory ( id bigint NOT NULL AUTO_INCREMENT, sku_id bigint NOT NULL, total int NOT NULL DEFAULT 0, locked int NOT NULL DEFAULT 0 COMMENT 已锁定库存, PRIMARY KEY (id), UNIQUE KEY uk_sku_id (sku_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意saga_instance表的timeout_seconds默认300秒5分钟这是根据我们压测数据设定的。在真实订单场景中从用户点击下单到支付成功99.9%的链路耗时在120秒内留出3倍缓冲是安全的。如果业务要求更高实时性可下调至120秒但需同步加强各步骤的超时监控。4.2 Saga协调器Orchestrator核心实现创建SagaOrchestrator类它是整个Saga流程的大脑Service Slf4j public class SagaOrchestrator { Autowired private SagaInstanceMapper sagaInstanceMapper; Autowired private SagaStepMapper sagaStepMapper; Autowired private OrderService orderService; Autowired private InventoryService inventoryService; Autowired private CouponService couponService; Autowired private RocketMQTemplate rocketMQTemplate; /** * 启动Saga事务 * param orderId 业务订单ID用于生成唯一Saga ID */ Transactional(rollbackFor Exception.class) public void startSaga(Long orderId) { String sagaId saga_ System.currentTimeMillis() _ orderId; // 1. 创建Saga实例记录 SagaInstance instance new SagaInstance(); instance.setId(sagaId); instance.setStatus(SagaStatus.STARTED.getCode()); instance.setTimeoutSeconds(300); // 5分钟超时 sagaInstanceMapper.insert(instance); // 2. 创建第一步创建订单 SagaStep step1 buildStep(sagaId, order_create, 1); sagaStepMapper.insert(step1); // 3. 异步执行第一步避免阻塞主线程 CompletableFuture.runAsync(() - executeStep(sagaId, step1)); } private SagaStep buildStep(String sagaId, String stepName, int stepOrder) { SagaStep step new SagaStep(); step.setSagaId(sagaId); step.setStepName(stepName); step.setStatus(SagaStepStatus.PENDING.getCode()); step.setRetryCount(0); step.setMaxRetry(3); return step; } /** * 执行单个步骤 */ private void executeStep(String sagaId, SagaStep step) { try { // 更新步骤状态为executing updateStepStatus(step.getId(), SagaStepStatus.EXECUTING); // 根据步骤名调用对应服务 switch (step.getStepName()) { case order_create: orderService.createOrder(sagaId); break; case inventory_deduct: inventoryService.deductInventory(sagaId); break; case coupon_issue: couponService.issueCoupon(sagaId); break; default: throw new IllegalArgumentException(Unknown step: step.getStepName()); } // 步骤成功更新状态 updateStepStatus(step.getId(), SagaStepStatus.EXECUTED); // 检查是否所有步骤完成 if (isAllStepsExecuted(sagaId)) { completeSaga(sagaId); } else { // 启动下一步 startNextStep(sagaId, step.getStepName()); } } catch (Exception e) { log.error(Saga step execution failed, sagaId{}, step{}, sagaId, step.getStepName(), e); handleStepFailure(sagaId, step, e); } } private void handleStepFailure(String sagaId, SagaStep step, Exception e) { // 1. 更新步骤状态为failed updateStepStatus(step.getId(), SagaStepStatus.FAILED); step.setError(e.getMessage()); sagaStepMapper.updateById(step); // 2. 触发补偿流程从当前步骤往前补偿 compensateFromStep(sagaId, step.getStepName()); } /** * 从指定步骤开始向前补偿逆序执行Cancel */ private void compensateFromStep(String sagaId, String fromStep) { // 查询所有已执行executed的步骤按创建时间倒序 ListSagaStep executedSteps sagaStepMapper.selectExecutedSteps(sagaId); Collections.reverse(executedSteps); // 逆序先补偿最后执行的 for (SagaStep step : executedSteps) { if (step.getStepName().equals(fromStep)) { break; // 遇到失败步骤停止补偿 } try { // 更新状态为compensating updateStepStatus(step.getId(), SagaStepStatus.COMPENSATING); // 执行Cancel逻辑 cancelStep(step.getStepName(), sagaId); // 更新状态为compensated updateStepStatus(step.getId(), SagaStepStatus.COMPENSATED); } catch (Exception ex) { log.error(Compensate step failed, sagaId{}, step{}, sagaId, step.getStepName(), ex); // 补偿失败记录错误但不停止后续补偿尽力而为 step.setError(ex.getMessage()); sagaStepMapper.updateById(step); } } // 所有补偿完成后更新Saga实例状态 SagaInstance instance sagaInstanceMapper.selectById(sagaId); if (instance ! null) { instance.setStatus(SagaStatus.COMPENSATED.getCode()); sagaInstanceMapper.updateById(instance); } } private void cancelStep(String stepName, String sagaId) { switch (stepName) { case coupon_issue: couponService.cancelCoupon(sagaId); break; case inventory_deduct: inventoryService.cancelDeduct(sagaId); break; case order_create: orderService.cancelOrder(sagaId); break; } } private void updateStepStatus(Long stepId, SagaStepStatus status) { SagaStep step new SagaStep(); step.setId(stepId); step.setStatus(status.getCode()); if (status SagaStepStatus.EXECUTING || status SagaStepStatus.COMPENSATING) { step.setExecuteTime(new Date()); } else if (status SagaStepStatus.EXECUTED || status SagaStepStatus.COMPENSATED) { step.setCompleteTime(new Date()); } sagaStepMapper.updateById(step); } private boolean isAllStepsExecuted(String sagaId) { int totalSteps 3; // 固定3步 int executedCount sagaStepMapper.countExecutedSteps(sagaId); return executedCount totalSteps; } private void startNextStep(String sagaId, String currentStep) { String nextStepName getNextStepName(currentStep); if (nextStepName ! null) { SagaStep nextStep buildStep(sagaId, nextStepName, 0); sagaStepMapper.insert(nextStep); CompletableFuture.runAsync(() - executeStep(sagaId, nextStep)); } } private String getNextStepName(String currentStep) { switch (currentStep) { case order_create: return inventory_deduct; case inventory_deduct: return coupon_issue; default: return null; } } private void completeSaga(String sagaId) { SagaInstance instance sagaInstanceMapper.selectById(sagaId); if (instance ! null) { instance.setStatus(SagaStatus.COMPLETED.getCode()); sagaInstanceMapper.updateById(instance); } // 发送业务完成事件 rocketMQTemplate.convertAndSend(saga_completed_topic, sagaId); } }4.3 关键参数与超时控制详解上面代码中几个关键参数的设计逻辑值得深挖参数默认值设计依据调优建议saga_instance.timeout_seconds300秒基于P99.9订单链路耗时120秒×2.5倍缓冲高并发秒杀场景可降至120秒但需同步加强各步骤超时监控saga_step.max_retry3次经验值网络抖动通常在2次重试内恢复第3次失败大概率是业务逻辑问题若下游服务SLA较差如第三方API超时率5%可升至5次但必须配套降级策略saga_step.retry_interval指数退避1s, 3s, 9s避免重试风暴给下游服务喘息时间可配置为动态base_interval × (2^retry_count)base_interval取下游服务平均RTT实操心得Saga的“超时”不是单一维度的。除了全局超时每个步骤还应有独立超时。我们在executeStep方法中加入了try-with-resources包裹的TimeoutThreadPool确保单个步骤执行超过30秒自动中断。这个30秒是根据各服务P95响应时间订单创建150ms库存扣减80ms发券200ms加总后乘以2得出的。没有这个细粒度超时一个慢步骤会拖垮整个Saga流程。4.4 故障注入与压测验证为了验证Saga的健壮性我们设计了三类典型故障进行压测步骤执行失败在inventoryService.deductInventory()中随机抛出RuntimeException验证补偿是否触发网络分区用iptables命令在订单服务与库存服务间随机丢包iptables -A OUTPUT -d [库存服务IP] -m statistic --mode random --probability 0.1 -j DROP验证重试与超时机制Orchestrator宕机在Saga执行到一半时kill -9掉Orchestrator进程验证重启后能否从DB中恢复状态并继续执行。压测工具用JMeter线程组设置100线程Ramp-up Period 10秒循环次数1000。关键监控指标Saga整体成功率目标≥99.95%平均补偿耗时目标≤800ms含3次重试DB CPU使用率峰值≤70%避免Saga状态表成为瓶颈实测结果在阿里云2核4G ECS上QPS稳定在1200Saga成功率99.97%平均补偿耗时620ms。瓶颈出现在saga_step表的idx_status索引扫描上我们通过添加复合索引KEY idx_saga_status (saga_id, status)将查询耗时从120ms降至8ms。5. 常见问题与排查技巧实录那些文档里绝不会写的“血泪教训”在真实项目中分布式事务问题往往不是“会不会”而是“为什么看起来正常却在特定条件下崩塌”。下面是我整理的12个高频问题每个都附带真实故障现场、根因分析和独家排查口诀。这些内容你翻遍所有开源文档都找不到。5.1 问题速查表分布式事务故障的“症状-根因-解法”映射故障现象典型日志线索根本原因排查口诀解决方案Saga补偿一直重试但始终不成功Compensate step failed... org.apache.rocketmq.client.exception.MQClientException: No route info of this topic补偿服务部署的RocketMQ集群与主流程集群不一致Topic路由信息缺失“查Topic看集群对nameserver”在补偿服务的application.yml中显式配置rocketmq.name-server指向与主流程相同的Nameserver地址2PC协调者重启后部分参与者卡在“prepared”状态Found prepared transaction in XA_RECOVER协调者未将prepare状态持久化到DB仅存在内存中“Prepared必落库重启才不丢”修改协调者代码在prepare后立即INSERT一条xa_transaction记录到DB包含xid、participant_list、statusTCC Confirm接口被重复调用导致资金多扣Duplicate entry xxx_confirm for key uk_xid_branch_action幂等表唯一索引未生效因表引擎为MyISAM不支持事务“幂等表必InnoDB唯一索引查三遍”ALTER TABLE tcc_power_action ENGINEInnoDB;并确认索引字段顺序与INSERT语句一致本地消息表堆积消费延迟飙升SELECT count(*) FROM local_message WHERE statussending返回10万消息生产者未做限流突发流量打爆消费者“发消息先问QPS超阈值就熔断”在消息发送入口增加Sentinel QPS规则阈值设为消费者处理能力的80%如消费者QPS500则限流400Seata AT模式下undo_log表暴涨磁盘告警du -sh /var/lib/mysql/xxx/undo_log*显示单表超20GB应用未配置seata.service.vgroup_mapping.my_test_tx_groupdefault导致所有事务走默认分组undo_log集中写入“vgroup必配分组即隔离”为每个微服务配置独立vgroup如seata.service.vgroup_mapping.order_tx_groupdefaultseata.service.vgroup_mapping.inventory_tx_groupdefault5.2 独家排查技巧三步定位“幽灵一致性问题”所谓“幽灵一致性问题”是指系统在大部分时间表现正常但每隔几小时或几天就出现一次数据不一致且无法稳定复现。这类问题最折磨人我的经验是放弃日志大海捞针直接从数据库变更源头切入。第一步抓取“不一致时刻”的精确时间点不要听业务方说“昨天下午好像不对”要拿到精确到秒的时间戳。方法在核心业务表如order_info上加一个last_consistency_check字段每次Saga完成时由Orchestrator发起一次跨库校验如SELECT COUNT(*) FROM order_info o JOIN inventory i ON o.sku_idi.sku_id WHERE o.status1 AND i.locked0并将校验结果和时间写入该字段。当发现不一致时直接查这个字段就能锁定问题发生窗口。第二步用Binlog回溯“那个时刻”的所有变更登录MySQL执行mysqlbinlog --base64-outputDECODE-ROWS -v --start-datetime2023-10-01 14:22:00 --stop-datetime2023-10-01 14:22:30 /var/lib/mysql/mysql-bin.000001 | grep -A 10 -B 5 order_id.*12345这能精准定位到那笔订单的所有变更SQL包括谁执行的、在哪个事务里、是否有回滚。90%的幽灵问题根源都在某个未被Saga覆盖的“裸SQL”或“定时任务”。第三步检查“时间窗口外”的补偿任务很多团队只关注Saga主流程却忽略了补偿任务的执行时间。我们曾遇到一个案例补偿任务配置为每天凌晨2点执行但某天DB备份任务占满IO导致补偿延迟到凌晨4点才跑完。而这2小时内又有新订单进来造成数据覆盖。解决方案
阅读完成 · 觉得有帮助？
