(4)什么时候引入Seata‘‘

非常好的问题！这两个问题正是技术选型时需要重点考虑的。

什么时候需要引入 Seata？

需要引入 Seata 的场景：

1. 跨数据库的分布式事务

// 订单服务（MySQL） + 库存服务（PostgreSQL） + 账户服务（Oracle）
@GlobalTransactional
public void createOrder() {
    orderService.create(); // MySQL
    storageService.deduct(); // PostgreSQL  
    accountService.pay(); // Oracle
}

1. 跨服务的业务操作

// 电商下单场景
@GlobalTransactional
public void placeOrder() {
    orderService.createOrder();      // 订单服务
    inventoryService.reduceStock();  // 库存服务
    paymentService.processPayment(); // 支付服务
    pointsService.addPoints();       // 积分服务
}

1. 资金交易等强一致性要求

// 转账操作必须同时成功或失败
@GlobalTransactional
public void transfer() {
    accountService.deduct(fromAccount, amount);  // 扣款
    accountService.add(toAccount, amount);       // 加款
    transactionService.recordTransfer();         // 记录交易
}

1. 库存管理关键操作

// 库存扣减和恢复
@GlobalTransactional
public void handleInventory() {
    inventoryService.lockStock();    // 锁定库存
    orderService.createOrder();      // 创建订单
    // 如果订单创建失败，库存自动解锁
}

不需要引入 Seata 的场景：

1. 单数据库事务

// 单个服务内的数据库操作
@Transactional // 本地事务足够
public void updateUser() {
    userDao.updateInfo();
    userDao.updateProfile();
}

1. 最终一致性可接受的场景

// 发送通知、记录日志等
public void userRegister() {
    userService.register(); // 本地事务
    // 通过消息队列异步处理
    mqService.sendWelcomeMsg(); // 最终一致性
}

1. 读多写少的场景

// 查询操作不需要分布式事务
public ProductInfo getProductDetail() {
    Product product = productService.getProduct();
    List<Review> reviews = reviewService.getReviews();
    // 不需要事务控制
    return assemble(product, reviews);
}

1. 性能要求极高的场景

// 高并发写入场景
public void recordClick() {
    // 直接写入，容忍少量数据不一致
    clickService.record();
    statisticService.update();
}

Seata 会不会导致性能问题？

会的，Seata 确实会带来性能开销，但可以通过优化控制在可接受范围内。

性能开销来源：

1. 网络开销

graph LR
A[TM] --> B[TC]
B --> C[RM1]
B --> D[RM2]
B --> E[RM3]

style A fill:#f9f
style B fill:#9cf

• • TM 与 TC 的 2 次通信
  • TC 与每个 RM 的 2 次通信
  • 网络延迟累积

1. 全局锁开销

-- Seata 需要获取全局锁
SELECT * FROM table WHERE id = 1 FOR UPDATE;
-- 全局锁会阻塞其他分布式事务

1. undo_log 操作开销

// 每个写操作都需要记录undo_log
// 1. 执行业务SQL
// 2. 生成before image
// 3. 生成after image  
// 4. 写入undo_log表

1. 同步阻塞开销

@GlobalTransactional // 同步阻塞直到所有分支完成
public void business() {
    serviceA.call(); // 阻塞
    serviceB.call(); // 阻塞
    serviceC.call(); // 阻塞
}

性能数据参考：

性能优化方案：

1. 架构层面优化

# 使用TCC模式替代AT模式
seata:
  mode: tcc  # 性能更好，但开发复杂

# 合理的超时设置
  timeout: 30000  # 避免长时间锁等待

1. 数据库优化

-- undo_log表优化
CREATE INDEX idx_undo_log_xid ON undo_log(xid);
CREATE INDEX idx_undo_log_status ON undo_log(log_status);

-- 定期清理
DELETE FROM undo_log WHERE log_created < DATE_SUB(NOW(), INTERVAL 7 DAY);

1. 部署优化

# Seata Server集群部署
seata:
  service:
    grouplist:
      default: 192.168.1.101:8091,192.168.1.102:8091,192.168.1.103:8091

# 客户端连接池优化
  client:
    rm:
      async-commit-buffer-limit: 10000  # 增加缓冲
      report-retry-count: 5  # 重试次数

1. 业务层面优化

// 1. 减少分布式事务范围
@GlobalTransactional
public void optimizedBusiness() {
    // 只包含必须事务性的操作
    essentialOperation1();
    essentialOperation2();
    // 非核心操作异步化
    asyncService.nonEssentialOperation();
}

// 2. 使用最终一致性替代强一致性
public void eventualConsistency() {
    localTransaction(); // 本地事务
    // 通过消息队列保证最终一致性
    mqService.sendAsyncMessage();
}

1. 监控和调优

# 开启监控
management:
  endpoints:
    web:
      exposure:
        include: metrics,seata

seata:
  metrics:
    enabled: true
    exporter-list: prometheus

决策建议

推荐使用 Seata when：

• ✅ 资金交易、订单创建等强一致性场景
• ✅ 跨多个数据库的关键业务操作
• ✅ 业务容忍 200-500ms 的延迟
• ✅ TPS 要求低于 1000 的业务场景

谨慎使用 Seata when：

• ⚠️ 高并发秒杀场景（TPS > 2000）
• ⚠️ 实时性要求极高的业务（延迟 < 50ms）
• ⚠️ 读多写少的业务场景
• ⚠️ 可以接受最终一致性的场景

替代方案考虑：

// 1. 本地消息表+消息队列
@Transactional
public void createOrder() {
    orderDao.insert(order);
    messageDao.insert(message); // 同一事务
    // 异步消费消息保证最终一致性
}

// 2. Saga模式（长事务）
public void longRunningTransaction() {
    // 每个步骤提供补偿操作
    step1();
    step2();
    step3();
    // 失败时执行补偿：compensate1(), compensate2()
}

// 3. 业务幂等+重试机制
@Retryable(maxAttempts=3)
public void idempotentOperation() {
    // 业务逻辑保证幂等性
}

总结

引入 Seata 会带来性能开销，但通过合理的设计和优化，可以将其控制在业务可接受的范围内。 关键是要根据业务场景做出合适的选择：

• 强一致性需求 → Seata
• 高性能要求 → 本地事务+最终一致性
• 长业务流程 → Saga模式
• 简单业务 → 重试+幂等性

建议先在预发环境进行性能测试，确保 Seata 的性能表现符合业务预期后再上生产环境。