Agent面经：从面试题解析到实战优化的全链路解决方案

共计 2032 个字符，预计需要花费 6 分钟才能阅读完成。

从订单状态同步问题看分布式事务痛点

前几天排查线上问题时，发现一个典型的分布式事务案例：用户支付成功后，由于订单服务和仓储服务状态同步延迟，导致系统触发了两次发货。这不仅造成了物流成本浪费，还引发了用户投诉。这个案例揭示了分布式系统的核心挑战——如何保证跨服务的数据一致性。

主流分布式事务方案对比

TCC 模式：适合强一致性场景

TCC（Try-Confirm-Cancel）模式通过三个阶段实现事务控制：

1. Try：预留业务资源（如冻结库存）
2. Confirm：确认执行业务（如扣减库存）
3. Cancel：取消预留（如释放库存）

优点：
– 保证强一致性
– 无锁设计减少资源占用

缺点：
– 业务侵入性强
– 需要实现所有反向操作

flowchart TD
    A[Try 阶段] -->| 成功 | B[Confirm 阶段]
    A -->| 失败 | C[Cancel 阶段]

SAGA 模式：适合长事务场景

SAGA 将大事务拆分为多个本地事务，通过补偿机制保证最终一致性：

1. 正向事务序列执行
2. 任一失败时触发逆向补偿

优点：
– 适合跨多服务的复杂流程
– 不需要资源预留

缺点：
– 存在中间状态
– 补偿逻辑可能失败

Spring Cloud + Seata 实战示例

以下是使用 Seata 实现订单创建的全局事务：

@GlobalTransactional(timeoutMills = 60000, name = "create-order-tx")
public void createOrder(OrderDTO orderDTO) {
    // 参数校验
    Validate.notNull(orderDTO, "订单数据不能为空");
    log.info("开始创建订单：{}", orderDTO.getOrderNo());

    // 1. 保存订单
    orderService.saveOrder(orderDTO);

    // 2. 扣减库存
    inventoryService.deduct(orderDTO.getSkuCode(), orderDTO.getQuantity());

    // 3. 生成物流单
    logisticsService.createShipment(orderDTO.getOrderNo());
}

关键点说明：
1. @GlobalTransactional注解开启全局事务
2. 超时时间应根据业务复杂度合理设置
3. 每个参与服务需配置seata.tx-service-group

RocketMQ 幂等处理方案

防止消息重复消费的典型实现：

@RocketMQMessageListener(topic = "order_paid", consumerGroup = "inventory_group")
public class OrderPaidConsumer implements RocketMQListener<MessageExt> {

    @Override
    public void onMessage(MessageExt message) {
        // 使用 bornTimestamp+msgId 作为幂等键
        String idempotentKey = message.getBornTimestamp() + "_" + message.getMsgId();

        if (redisTemplate.opsForValue().setIfAbsent("idempotent:"+idempotentKey, "1", 24, TimeUnit.HOURS)) {
            // 处理核心业务逻辑
            handleOrderPaid(message);
        } else {log.warn("重复消息已跳过：{}", idempotentKey);
        }
    }
}

性能优化实战数据

TCC 各阶段耗时测试（单位：ms）

事务日志表索引优化

推荐索引组合：

ALTER TABLE transaction_log 
ADD INDEX idx_xid_status (xid, status);

字段顺序说明：
1. 优先按全局事务 ID(xid)查询
2. 状态字段 (status) 用于筛选未完成事务

生产环境避坑指南

防范悬挂问题

当子事务比父事务先执行时，会出现悬挂问题。解决方案：

1. 在 Try 阶段检查父事务是否存在
2. 增加事务状态校验接口

补偿接口雪崩保护

线程池配置公式：

队列容量 = 平均处理速率 * 最大可接受延迟

示例配置：

# 假设 QPS=100，可接受延迟 2s
thread-pool.core-size=20
thread-pool.max-size=50
thread-pool.queue-capacity=200

思考题：跨时区事务同步

当业务涉及跨时区系统时，如何解决时钟漂移带来的事务一致性问题？可以考虑：

1. 采用 NTP 时间同步协议
2. 使用逻辑时钟替代物理时钟
3. 在事务元数据中记录时区信息

欢迎在评论区分享你的解决方案。在实际业务中，我们最终采用了 ” 本地时间 + 时区偏移量 ” 的方案，配合 Quartz 的时区感知调度器，较好地解决了跨时区订单处理问题。