TCC与Saga分布式事务方案对比：原理、选型与订单库存实战

上周五下午，我们组正在讨论一个老订单系统的拆分方案，产品同学突然问了一句："如果用户下单时支付成功但是库存没扣掉，这个账怎么算？"会议室瞬间安静了三秒。

这个场景对做过微服务改造的人来说太熟悉了。单体应用里一条事务就能搞定的事，拆成订单服务、库存服务、支付服务之后，变成了跨服务的分布式事务问题。而一聊到分布式事务的解决方案，绕不开的两个词就是TCC和Saga。很多人上来就问"哪个好"，但选型这事从来就不是二选一那么简单。这篇文章我就把这两种方案摊开来说清楚，从原理、实现、落地到踩坑，结合订单和库存这个最经典也最要命的场景，聊一聊到底怎么选、怎么落地。

如果你是正在做微服务拆分、或者被分布式事务折磨过的后端工程师，这篇文章应该能帮你省下不少调研时间。本文会先讲清楚TCC和Saga各自的原理、适用边界和隐藏成本，然后给出一个订单+库存场景的完整实现推演，最后把我自己遇到过的几个线上问题和不传出去的排查思路都摊出来讲。

1. 为什么微服务化之后，分布式事务成了绕不过去的坎

1.1 从一次下单说起：本地事务怎么"失效"的

先回到最基础的场景。在单体架构时代，下单操作是这样完成的：创建一个订单记录、扣减库存、如果开通了会员还要加积分，整个过程在同一个数据库连接里完成，包在一个BEGIN TRANSACTION和COMMIT之间。任何一个步骤失败，整体回滚，数据不会出现"订单在但库存负了"的情况。

拆成微服务之后，订单、库存、积分各自有独立的数据库。下单接口变成了三个远程调用：

• 订单服务写一条订单记录
• 库存服务扣减库存
• 积分服务增加积分

这时候如果库存扣减成功了，但积分服务超时了，怎么办？订单服务没法把库存服务的数据库一起回滚，因为那是另一个服务、另一套数据库、甚至可能跑在另一台机器上。这就是分布式事务要解决的问题：多个独立的数据节点之间，如何保证数据最终能落到一个一致的状态。

1.2 CAP理论：分布式事务的本质是取舍

要说清楚TCC和Saga的区别，得先回到CAP理论。分布式系统里，网络分区（P）是不可避免的，这时候只能在一致性（C）和可用性（A）之间做取舍。

注意，CAP里的"一致性"指的是线性一致性，也就是所有节点在同一时刻看到的数据都是一样的。这在分布式场景下几乎不可能严格做到，因为数据同步需要网络传输，有延迟。所以现实中很多系统做的是"最终一致性"——允许中间有个短暂的不一致窗口，但在某个时间点之后，所有节点的数据会收敛到一致状态。

TCC和Saga本质上是两种不同的取舍策略：

• TCC更偏向"强一致性"的妥协方案，通过资源预留机制，把不一致的窗口压缩到最小
• Saga则是典型的"最终一致性"方案，允许中间步骤是可见的、不一致的，通过补偿机制把状态拉回来

1.3 为什么不直接上两阶段提交（2PC）

很多刚接触分布式事务的人会问：既然要强一致，为什么不直接用2PC？2PC确实是最经典的一致性协议，有XA这种标准化实现，很多数据库原生支持。

但2PC在实际落地中问题不少：

• 同步阻塞：第一阶段准备完成后，所有参与者都要持有资源锁等待协调者决策，长事务场景下数据库连接很容易被耗尽
• 单点风险：协调者挂了，事务卡在"已准备"状态，所有资源锁全部锁死
• 网络分区下的fork问题：协调者与参与者之间网络闪断，参与者无法收到最终决策，只能一直等下去

很多银行核心系统在存量场景下还在用XA，但互联网业务普遍放弃了这条路，原因就是"锁时间太长、并发能力太差"。TCC和Saga把锁的粒度从"数据库行锁"降到了"业务层的预留状态"，用代码逻辑换性能，这才是它们被广泛应用的核心逻辑。

2. TCC方案核心拆解：强一致性背后的"手工活"

2.1 TCC三阶段原理：Try、Confirm、Cancel到底在干什么

TCC（Try-Confirm-Cancel）是把一个业务动作拆成三段来执行：

• Try阶段：完成业务检查并预留资源，但还没有真正生效。这一步的核心是"锁定状态"
• Confirm阶段：真正执行业务，把Try阶段预留的资源变成实际扣减
• Cancel阶段：回滚，把Try阶段预留的资源释放掉

以库存扣减为例，真正的SQL逻辑是这样的：

sql复制-- Try阶段：检查库存足够，冻结库存
UPDATE stock SET frozen = frozen + #{count} 
WHERE sku_id = #{skuId} AND stock >= #{count};

-- Confirm阶段：冻结转扣减
UPDATE stock SET stock = stock - #{count}, frozen = frozen - #{count}
WHERE sku_id = #{skuId};

-- Cancel阶段：解冻
UPDATE stock SET frozen = frozen - #{count}
WHERE sku_id = #{skuId};

注意这三个操作都是独立的事务，由TCC事务管理器协调。Try全部成功后，再逐个调Confirm；任何一个Try失败，已经成功的参与者都要执行Cancel回滚。

关键点在于：Try阶段其实已经把资源"占住"了，所以Confirm阶段理论上不会失败。这就是TCC被称为"接近强一致"的原因——真正会失败的大部分情况都发生在Try阶段，而Try是可以被提前拦截的。

2.2 TCC的设计与实现边界

我自己实现过一轮TCC框架，踩了不少坑之后总结出三条边界：

第一，Try阶段要尽量把验证逻辑做完整。库存够不够、账户余额够不够、状态是不是正常，这些业务规则尽可能在Try阶段就全部判断完，否则Confirm阶段一旦出现业务失败，就打破了"Confirm不会失败"的假设，只能靠重试和补偿兜底，那整个TCC的优势就没了。

第二，Confirm和Cancel必须做到幂等。分布式环境下，网络超时后的事务管理器重试、消息队列的重复投递，都会导致Confirm或Cancel被调用多次。如果代码没做幂等保护，就会出现库存被重复扣减、冻结金额被重复恢复的问题。最容易的方案是在参与者表里记录事务状态，每次执行前先查询状态：

java复制@Transactional
public boolean confirmDeductStock(String txId, Long skuId, Integer count) {
    // 先查事务状态，防止重复confirm
    StockFrozenDO frozen = stockFrozenMapper.selectByTxId(txId);
    if (frozen == null || frozen.getStatus() == 1) {
        return true;  // 已确认过或者事务不存在，直接返回
    }
    // 冻结转扣减
    stockMapper.confirmDeduct(skuId, count);
    // 更新冻结单状态
    stockFrozenMapper.updateStatus(txId, 1);
    return true;
}

第三，TCC的每个操作粒度要合理。不要把多个独立的业务动作塞进同一个TCC事务里，比如"扣库存+加积分"虽然都属于下单动作，但它们的生命周期和补偿策略不同，硬塞进一个事务会让事务边界变得特别模糊，出问题的时候极难排查。宁可拆成两个TCC事务，用编排层串起来。

2.3 TCC的代价：业务侵入性到底有多高

要特别说明的是，TCC不是"引入一个框架"就完事的事情。它是一种业务设计模式，需要业务方自己实现Try、Confirm、Cancel三个方法，而且每个方法都要有完整的业务逻辑和幂等保护。

成本是成倍增加的。原来一个库存扣减方法只需要写UPDATE stock SET stock = stock - 1，现在要拆成三个方法，每个方法还要处理状态流转、幂等控制、异常分支。一个中等规模的系统，如果全部用TCC改造，开发量大概是原来的三到五倍。

所以TCC适合用在真正核心的、一致性要求高的链路上，比如支付、库存、账户扣款。像"记录日志"、"发短信通知"这种操作，没必要用TCC，把成本花在那里纯属浪费。

3. Saga方案核心拆解：最终一致性的"战术妥协"

3.1 Saga的两种模式：编排式与协同式

Saga模式的核心思想是把一个长事务拆成多个短事务（也叫局部事务），每个短事务都对应一个补偿动作（Compensation）。短事务之间依次执行，一旦某个环节失败，就反向执行之前所有环节的补偿操作。

Saga在实现方式上分两大流派：

编排式（Orchestration）由一个中心化的Saga编排器（通常是状态机）控制整个流程。编排器知道完整的流程顺序，调用服务A、等结果、调用服务B、等结果，失败时按相反顺序调用补偿。

协同式（Choreography）没有中心节点，服务之间通过事件驱动串联。服务A完成本地事务后发布事件，服务B收到事件后执行自己的事务，再发布新事件。补偿也是事件驱动，每个服务自己监听失败事件并处理。

两种方式各有利弊。编排式更容易追踪和管理，核心流程都在一个状态机里，出了问题看日志一目了然；协同式没有中心依赖，服务之间解耦，但流程分散在多个服务的事件处理器里，排查问题时要顺着事件链跑一遍，复杂度不低。

3.2 Saga的长事务优势与隔离性问题

Saga相比TCC最突出的优势是：事务的时长不受数据库锁的限制。TCC虽然在业务层"预留"了资源，但预留资源这件事本身也要求锁（比如冻结库存要更新stock表，这个操作在数据库层面还是会锁行），只是锁的时间比2PC短。如果事务执行需要几小时甚至跨天，TCC方案里这些资源一直被"占住"，并发能力会急剧恶化。

Saga的每个局部事务都立刻提交并释放数据库锁，下一个局部事务接着执行。中间状态对其他服务是可见的，所以Saga天然是最终一致性的。

这个"中间状态可见"既是优势也是风险。以订单+库存来举例：Saga流程是"创建订单 → 扣减库存"，如果订单创建成功后、扣减库存之前，用户去查询订单，看到的状态是"订单存在但这是不是有货"？这个中间态暴露给用户，体验和逻辑上都可能出问题。

缓解方案是引入业务状态位：创建订单时先把订单状态置为"创建中"或"待确认"，整个Saga流程结束后才改为"已创建"。这样外部查询时虽然能看到订单记录，但状态标识让语义变得明确。很多系统还会加一层"防止用户访问中间态"的开关，比如下单后不展示订单详情，等回调通知后再展示。

3.3 Saga补偿设计的关键：补偿动作必须能成功

这是我做Saga最有体会的一点：很多人设计了补偿逻辑，但没想过补偿动作本身会失败。

比如订单服务要先"创建订单"再"扣库存"，如果后面扣库存失败了，补偿动作是"把订单标记为已取消"。这个动作本身也有依赖，比如要更新订单表、可能要发消息通知用户。如果补偿执行的时候订单服务本身挂了，或者数据库连接出了问题，整个Saga就会卡在"待补偿"状态。

所以补偿设计要遵循几个原则：

• 补偿动作要尽可能简单，只做撤销操作，不做新的业务判断
• 补偿动作要有重试机制，比如本地消息表 + 定时重试，或者死信队列
• 需要人工兜底通道，实在补偿不了的时候，至少有监控告警和一个手工处理入口

另外，补偿动作必须幂等。网络重试、消息重复投递，会导致同一个补偿执行多次。最简单的幂等方案是记录补偿状态字段，比如订单表加一个saga_status字段，补偿执行时先判断状态是否已经回滚过。

4. TCC和Saga的选型对比：五个关键维度

4.1 一致性强度、隔离性与业务侵入度

把TCC和Saga放到五个维度上做对比，选型时最好逐个打分：

这里有个容易被忽略的细节：区分业务特性和技术处理逻辑的不同情况。

场景一：交易短流程，数据敏感度高

我实际经历过的场景是支付系统里维护买家钱包、账户余额变更。这类操作通常毫秒级完成，并发量大，数据敏感度极高，不能出现"用户余额显示扣了但支付单显示未成功"这种应用层不一致。选TCC是合适的，因为可以把"冻结余额"这个状态在应用层锁住，保证一致性下的体验。

场景二：业务链路长，涉及外部系统，可容忍短暂不一致

例如跨境电商的完整下单流程：创建订单、扣库存、对接支付渠道、物流创建运单、通知仓库发货。这些环节可能持续数秒，用户体验本身就需要等待，而且对接第三方系统时对方并不会配合你实现Try/Confirm/Cancel。选Saga合理，每个环节独立提交、失败即补偿。

4.2 业务重要性分级：并不是所有业务都值得上TCC

我见过一个团队在规划分布式事务方案时，一口气把全链路都改成TCC，开发了一个月，进度差一半，线上还出了不少问题。核心原因是他们忽略了一个常识：分布式事务是有成本的，如果业务在一段时间内允许"对账补偿"这种异步修复机制来保障，甚至不一定需要这么强的一致性保障。

要给业务分级：

• 核心资金链路（支付、退款、余额变动）：优先TCC
• 库存、订单等强约束场景：可以TCC，也可以用Saga+状态位
• 辅助链路（发短信、加积分、发券）：通常只需要本地事务+异步重试就已足够

4.3 团队熟悉度与技术栈的匹配

还有一个选型维度，我建议排在前面：团队对哪一套方案更熟悉。

如果团队过去做过消息驱动架构，对事件流的处理、幂等、死信队列都比较熟，Saga的落地难度会低很多。如果团队更习惯"接口调用+事务管理"的思维，TCC可能更容易理解，但要准备好面对三方法带来的开发量。

从框架生态看：Seata同时支持AT、TCC、Saga三种模式，而且社区活跃度高，Java技术栈下优先考虑。ServiceComb Pack的Saga也维护得不错。如果用的是Go，dtm（分布式事务管理器）也是个不错的选择，TCC和Saga都支持。

5. 订单+库存分布式事务：一个完整实战推演

5.1 场景定义与事务边界划分

现在把前面所有理论落到一个具体场景：用户下单购买商品，核心动作是两步——创建订单、扣减库存。

在这个场景下，先明确事务边界：

• 订单服务：创建订单记录，状态初始为"创建中"（CREATING）
• 库存服务：扣减商品库存，并返回成功或失败

这个场景里有一个核心的不变量：订单最终状态与库存扣减结果必须一致。订单不能出现"已付款但没扣到库存"的情况，也不应该出现"库存扣了但订单没创建成功"的情况。

为什么订单状态初始是"创建中"而不是"已创建"？这是为了给后面两种方案都留出状态流转的余地。不管是TCC的Confirm还是Saga的补偿，最终都要把订单状态落到一个终态。在设计表结构时就把这个状态字段想清楚，后面改造会省很多事。

5.2 用TCC实现订单+库存

订单服务的TCC三个方法：

• Try：创建一条"创建中"状态的订单记录（资源预留）
• Confirm：把订单状态改为"已创建"
• Cancel：把订单状态改为"已取消"

库存服务的TCC三个方法：

• Try：检查库存充足，并冻结指定数量库存
• Confirm：把冻结库存转为实际扣减
• Cancel：解冻库存

数据库侧需要一张库存冻结表：

sql复制CREATE TABLE stock_frozen (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  tx_id VARCHAR(64) NOT NULL COMMENT '分布式事务ID',
  sku_id BIGINT NOT NULL,
  order_id BIGINT NOT NULL,
  frozen_count INT NOT NULL COMMENT '冻结数量',
  status TINYINT NOT NULL DEFAULT 0 COMMENT '0-冻结中，1-已扣减，2-已解冻',
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL,
  UNIQUE KEY uk_tx_sku (tx_id, sku_id),
  KEY idx_order_id (order_id)
) COMMENT '库存冻结表';

库存Try阶段的代码：

java复制@Transactional
public boolean tryDeductStock(String txId, Long skuId, Long orderId, Integer count) {
    // 1. 幂等校验：如果txId已经存在，直接返回成功
    StockFrozenDO existing = stockFrozenMapper.selectByTxId(txId);
    if (existing != null) {
        return true;
    }
    // 2. 业务检查：库存是否充足（乐观锁，带条件更新）
    int rows = stockMapper.freezeStockIfEnough(skuId, count);
    if (rows == 0) {
        // 库存不足，记录失败日志
        return false;
    }
    // 3. 记录冻结明细
    StockFrozenDO frozen = new StockFrozenDO();
    frozen.setTxId(txId);
    frozen.setSkuId(skuId);
    frozen.setOrderId(orderId);
    frozen.setFrozenCount(count);
    frozen.setStatus(0);
    stockFrozenMapper.insert(frozen);
    return true;
}

其中freezeStockIfEnough的SQL：

sql复制UPDATE stock 
SET frozen = frozen + #{count}
WHERE sku_id = #{skuId} AND stock >= #{count}

这里用带条件的UPDATE代替先SELECT再UPDATE，既避免了并发下的超卖问题，也省去了显式加锁。如果库存不足，影响行数为0，Try直接返回失败，TCC事务管理器会去协调其他参与者做Cancel。

Confirm阶段：

java复制@Transactional
public boolean confirmDeductStock(String txId) {
    StockFrozenDO frozen = stockFrozenMapper.selectByTxId(txId);
    if (frozen == null || frozen.getStatus() == 1) {
        return true;  // 不存在或已确认，幂等处理
    }
    // 冻结转扣减
    stockMapper.confirmDeduct(frozen.getSkuId(), frozen.getFrozenCount());
    // 更新冻结单状态
    stockFrozenMapper.updateStatus(txId, 1);
    return true;
}

Cancel阶段：

java复制@Transactional
public boolean cancelDeductStock(String txId) {
    StockFrozenDO frozen = stockFrozenMapper.selectByTxId(txId);
    if (frozen == null || frozen.getStatus() == 2) {
        return true;  // 不存在或已解冻
    }
    if (frozen.getStatus() == 1) {
        // 已经Confirm了还要回滚，说明发生了反向补偿，理论上不应该出现
        // 这里要发告警，人工介入
        log.error("frozen already confirmed, txId={}", txId);
        return false;
    }
    // 解冻：reduce frozen
    stockMapper.releaseFrozenStock(frozen.getSkuId(), frozen.getFrozenCount());
    stockFrozenMapper.updateStatus(txId, 2);
    return true;
}

5.3 用Saga实现订单+库存

同样的场景用Saga实现，思路完全不同。Saga不需要冻结库存，而是直接执行扣减，失败再恢复。

流程设计：

1. 订单服务创建订单，状态为"创建中"，发布OrderCreatedEvent
2. 库存服务监听OrderCreatedEvent，执行真实扣减
3. 扣减成功，发布StockDeductedEvent，订单服务把订单状态改为"已创建"
4. 扣减失败，发布StockDeductFailedEvent，订单服务执行补偿——把订单状态改为"已取消"

代码层面：

java复制// 订单服务：创建订单
@Transactional
public Order createOrder(OrderCreateDTO dto) {
    Order order = new Order();
    order.setUserId(dto.getUserId());
    order.setStatus("CREATING");
    orderMapper.insert(order);
    // 事务提交后发布事件
    DomainEventPublisher.publishAfterCommit(new OrderCreatedEvent(order.getId(), dto.getSkuId(), dto.getCount()));
    return order;
}

// 库存服务：消费事件，扣库存
@EventListener
@Transactional
public void onOrderCreated(OrderCreatedEvent event) {
    int rows = stockMapper.deductStock(event.getSkuId(), event.getCount());
    if (rows > 0) {
        DomainEventPublisher.publishAfterCommit(new StockDeductedEvent(event.getOrderId()));
    } else {
        DomainEventPublisher.publishAfterCommit(new StockDeductFailedEvent(event.getOrderId(), "库存不足"));
    }
}

在这个流程里，事件发布必须和本地事务在同一个事务里，否则会存在"事务提交了但事件丢了"的问题。常见的做法是本地消息表：本地事务里写业务数据+写事件记录到同一张数据库表，然后由一个后台任务扫描这张表并发送消息。

5.4 同一个场景，两种方案怎么选

说句实话，订单+库存这种场景，我大概率会选TCC。原因有两个：

第一，库存扣减是高频核心操作，不允许出现"短暂不一致"导致的超卖。Saga的最终一致性在极端情况下可能出现这样的时序：扣减库存成功 → 订单状态还是"创建中" → 用户刷新看到订单，同时又看到库存少了。虽然可以通过状态位规避，但总归要增加额外的开发量。

第二，库存扣减本身就是一个短操作，一个TCC事务的耗时不会超过几百毫秒，TCC"预留资源"带来的并发影响完全可以接受。这种场景恰好在TCC的最佳射程范围内。

但如果订单链路很长，比如"创建订单 → 扣库存 → 扣款 → 减积分 → 发优惠券"，每个环节都参与TCC会让整个链路非常脆弱。这种情况下，我会考虑把主链路用Saga串起来，核心环节（扣库存、扣款）单独用TCC保护，形成一个混合方案。这不是"标准答案"，但确实是很多生产环境中的真实形态。

6. 实战中的常见问题与排查技巧

6.1 空回滚与悬挂：TCC的两个经典坑

空回滚和悬挂是TCC实现中最容易踩的两个坑，也是很多TCC框架不成熟时线上事故的根源。

空回滚指的是：Try没有执行成功，事务管理器却发起了Cancel。为什么会这样？比如订单服务在调用库存服务的Try时网络超时了，但超时不一定意味着Try失败，可能是Try已经执行完了，只是响应超时。协调器等不到响应，只能走Cancel流程。但此时库存服务的Try可能根本没执行（比如网络真的断了），Cancel却已经来了。

如果Cancel里默认了"Try肯定执行过"，就会出现问题：库存扣减的是stock里的实际库存，而Try还没冻结过，Cancel解冻时就会把别人的库存"解"出来，导致库存虚增。

解决方案是引入状态机记录冻结明细。Cancel执行时先查冻结表，如果查不到记录，说明Try没执行过，直接返回成功。这就是空回滚的标准处理方式。

悬挂则是反过来：Cancel已经执行完了，Try的请求才姗姗来迟。为什么会有这种时序？比如Round-robin负载均衡下，同一请求的不同阶段落在了不同实例上，前一个实例已经完成了Cancel，另一个实例的Try请求还在路上。

悬挂的可怕之处在于：Try执行后资源被冻结了，但永远不会有Confirm或Cancel来释放它，冻结库存卡在状态0，变成"僵尸资源"。解决思路也是状态判断：Try执行前先查冻结状态，如果该事务ID的状态已经是"已取消"，则拒绝执行Try。

6.2 幂等与重复调用：从一条重复扣减日志说起

线上环境排查过一次Saga重复执行问题。当时运维反馈说"同一笔订单被扣了两次库存"，查了日志发现同一个OrderCreatedEvent被消费了两次。

原因：消息队列的"至少一次"投递语义。消费者处理完消息后，还没来得及提交offset，消费者就挂了。消息重新投递时，如果消费者不具备幂等处理能力，就会重复执行扣减。

排查思路是这样的：先确认事件里有没有全局唯一业务ID（可以用订单ID+操作类型拼接），再检查消费处理的入口是否做了幂等判断。我当时在冻结记录表里根据订单ID查了索引，发现两条重复记录都关联了同一笔订单，确认是幂等没做好。

修复方案是加一张消费幂等表，主键设计成业务唯一键（比如order_id + event_type）。消费时先用INSERT IGNORE插入幂等记录，插入成功才执行后续业务：

sql复制-- 消费前先记录幂等键，唯一键冲突说明已消费过
INSERT IGNORE INTO event_consumed (event_id, consumer, consumed_at)
VALUES (#{eventId}, 'stock-service', now());

-- INSERT IGNORE返回0说明已存在，直接跳过

6.3 异常恢复与对账补单机制

无论TCC还是Saga，真正生产环境里都免不了兜底方案。因为分布式系统故障的可枚举性实在太低，变量太多，单纯依赖事务管理器重试是不够的。

我常用的兜底方案是"事务日志表 + 定时对账任务"。

以TCC为例，参与者的每次Try/Confirm/Cancel都在事务日志表里留痕，记录事务ID、参与方、状态、时间。后台跑一个对账任务，扫描那些超过指定时间还没进入终态的事务，主动查数据库侧的状态，判断是继续重试还是告警人工介入。

对账任务不能用简单的定时任务糊弄，要设计成可重入的、可熔断的。比如某个服务持续失败，对账任务不能无限重试把服务打死，要有退避策略，比如指数退避+最大重试次数，超过阈值发告警转人工。

有一个小技巧：对账任务和业务服务共享一套事务状态表，但查询条件要设计好索引，避免全表扫描。事务ID要全局唯一，建议直接用UUID或雪花ID，中间不要用数据库自增ID，否则跨服务追踪会非常痛苦。

6.4 性能瓶颈的排查思路

TCC和Saga在性能问题上表现不同，排查思路也完全不一样。

TCC的性能瓶颈通常出现在预留资源的锁竞争上。比如某个热门商品SKU的库存量只有100，所有用户的Try都去冻结这100个库存，即使冻结操作本身是行级UPDATE，100个并发用户同时操作同一行，锁竞争也会让响应时间飙升。排查思路是看数据库的行锁等待时间，如果锁等待占比高，说明限制瓶颈在并发扣减上。解决办法有几种：库存拆分（热点SKU拆成多行库存）、串联队列化、或者引入独立的库存预占服务，走异步化路径。

Saga的性能瓶颈更多出现在事件处理链路的不匹配上。比如某个中间环节的服务处理速度慢，事件在消息队列里堆积，整体流程耗时拉长。定位方法比较直观：看消息队列的consumer lag。如果积压持续增长，就要评估是加消费者实例、改批量消费，还是优化处理逻辑。

还有一个容易被忽略的点：Saga里每个局部事务的补偿需要读取参与者的状态，如果状态表数据量很大且没建好索引，补偿速度会拖累整个Saga的恢复时间。这里建议定时对状态表做归档，保留最近一周的活跃事务数据即可。

7. 最后的体会

TCC和Saga不是非此即彼的关系。实际生产里我见到最多的是"混合方案"：核心链路TCC保一致，长流程Saga做最终一致，对外部系统的调用则依赖本地消息表+重试。

选型的判断标准也没有那么神秘，无非是三个问题：这个业务能容忍多久的不一致？这个操作占用的资源能锁多久？出了故障团队有没有能力兜住？把这三个问题想清楚，再回过头看TCC和Saga，答案自然会浮现。

最后再贡献一个小技巧：无论选哪种方案，事务日志一定要留全。分布式事务的排查极度依赖链路追踪和状态记录，如果日志只打"成功"或"失败"而不记录事务ID、参与方、耗时、重试次数，出问题的时候只能靠猜。我见过太多项目花大力气选了事务方案，最后栽在"查不到现场"上，这一点务必提前做好。