做过分布式事务的同学肯定都遇到过这个问题：在高并发场景下，多个事务同时更新同一条记录时，由于 Seata 全局锁的竞争，大部分请求都会陷入等待状态，导致响应时间急剧增加，甚至超时。

我之前就遇到过这样一个案例：在一个库存扣减场景中，100 个并发请求同时扣减同一个商品的库存，结果只有第一个请求能成功获取全局锁，其他 99 个请求都在等待锁释放，导致平均响应时间超过 10 秒，大量请求超时失败。

今天我们就来聊聊 Seata 全局锁等待的优化方案，让您的分布式事务在高并发场景下依然能保持高性能。

全局锁等待问题的根源

1. Seata 全局锁机制

Seata 的 AT 模式使用全局锁来保证分布式事务的一致性：

Seata 全局锁流程：

1. 第一阶段（准备）：
   - 本地事务执行前，先获取全局锁
   - 如果获取失败，等待锁释放
   - 默认等待时间 30 秒

2. 第二阶段（提交/回滚）：
   - 事务协调器通知所有分支事务提交或回滚
   - 提交时释放全局锁

问题场景：
请求1 → 获取全局锁 → 更新数据 → 等待提交
请求2 → 等待全局锁（最多等30秒）→ 超时失败
请求3 → 等待全局锁（最多等30秒）→ 超时失败
...

2. 热点行更新的雪崩效应

当多个事务同时更新同一条记录时：

假设库存扣减场景：
- 商品A库存：100
- 并发请求：100个
- 每个请求扣减1

执行过程：
请求1: 获取锁 → 扣减 → 等待提交（500ms）
请求2-100: 等待锁 → 超时（30秒）

结果：
- 1个成功，99个失败
- 吞吐量：1/30 ≈ 0.03 QPS
- 平均响应时间：> 30秒

3. 默认配置的缺陷

Seata 默认的锁等待配置存在问题：

默认配置：
- lock.lockRetryInterval: 10ms
- lock.lockRetryTimes: -1（无限重试）
- transaction.default-global-lock-expire-time: 60000ms

问题：
1. 无限重试导致线程长期阻塞
2. 重试间隔太短，增加锁竞争
3. 锁过期时间过长，死锁时影响大

解决方案：本地重试 + 快速失败

1. 核心设计思想

我们的方案核心是三个关键技术：

1. 本地重试机制：在获取全局锁失败时，本地进行有限次重试
2. 快速失败策略：超过重试次数后立即返回，不长期阻塞
3. 指数退避：重试间隔指数增长，减少锁竞争

架构图如下：

┌─────────────────────────────────────────────────────────────────┐
│                    全局锁优化架构                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────┐    ┌────────────────┐    ┌────────────────┐      │
│  │  请求    │───→│  业务方法      │───→│  全局锁获取    │      │
│  │          │    │                │    │                │      │
│  └──────────┘    └────────────────┘    └────────────────┘      │
│                                              │                 │
│                              ┌───────────────┴───────────────┐ │
│                              ▼                               ▼ │
│                      ┌───────────┐                    ┌───────────┐│
│                      │ 获取成功  │                    │ 获取失败  ││
│                      │           │                    │           ││
│                      └────┬──────┘                    └────┬──────┘│
│                           │                                │      │
│                           ▼                                ▼      │
│                   ┌─────────────┐                 ┌─────────────┐ │
│                   │ 执行业务    │                 │ 本地重试    │ │
│                   │             │                 │ (有限次)    │ │
│                   └─────────────┘                 └─────────────┘ │
│                                                         │        │
│                                               ┌─────────┴─────────┐│
│                                               ▼                 ▼ ││
│                                         ┌───────────┐      ┌───────────┐│
│                                         │ 重试成功  │      │ 重试失败  ││
│                                         │           │      │           ││
│                                         └────┬──────┘      └────┬──────┘│
│                                              │                 │      │
│                                              └────────┬────────┘      │
│                                                       ▼              │
│                                               ┌─────────────┐        │
│                                               │ 执行业务    │        │
│                                               └─────────────┘        │
│                                                                      │
└───────────────────────────────────────────────────────────────────────┘

2. 本地重试机制

// 全局锁重试注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface GlobalLockRetry {
    int maxRetries() default 3;
    long initialDelay() default 100;
    long maxDelay() default 1000;
}

// 重试拦截器
class GlobalLockRetryInterceptor implements MethodInterceptor {
    
    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {
        GlobalLockRetry annotation = invocation.getMethod()
                .getAnnotation(GlobalLockRetry.class);
        
        int maxRetries = annotation.maxRetries();
        long initialDelay = annotation.initialDelay();
        long maxDelay = annotation.maxDelay();
        
        long currentDelay = initialDelay;
        int retryCount = 0;
        
        while (true) {
            try {
                return invocation.proceed();
            } catch (LockWaitTimeoutException e) {
                if (retryCount >= maxRetries) {
                    throw new BusinessException("获取全局锁超时，已重试" + retryCount + "次");
                }
                
                retryCount++;
                log.warn("第{}次获取全局锁失败，等待{}ms后重试", retryCount, currentDelay);
                
                Thread.sleep(currentDelay);
                currentDelay = Math.min(currentDelay * 2, maxDelay);
            }
        }
    }
}

3. 快速失败策略

// 快速失败配置
class FastFailConfig {
    // 是否启用快速失败
    private boolean enabled = true;
    // 最大重试次数
    private int maxRetries = 3;
    // 初始重试间隔（毫秒）
    private long initialDelay = 100;
    // 最大重试间隔（毫秒）
    private long maxDelay = 1000;
    // 是否启用指数退避
    private boolean exponentialBackoff = true;
}

4. 指数退避算法

指数退避算法：

currentDelay = initialDelay * (2 ^ retryCount)

示例：
初始延迟：100ms
重试次数：3次

重试1: 等待 100ms * 2^0 = 100ms
重试2: 等待 100ms * 2^1 = 200ms
重试3: 等待 100ms * 2^2 = 400ms

总等待时间：100 + 200 + 400 = 700ms

对比无限等待（默认30秒）：
- 优化后：最多等待 700ms
- 优化前：最多等待 30秒
- 提升：42倍

最佳实践与配置建议

1. 合理设置重试参数

# 全局锁优化配置
seata:
  lock:
    retry:
      enabled: true
      max-retries: 3
      initial-delay: 100
      max-delay: 1000
      exponential-backoff: true

2. 热点数据隔离

热点数据隔离策略：

1. 库存分段：将库存分成多个段，分散锁竞争
   - 商品A库存100 → 分成10段，每段10
   - 请求随机选择一段扣减
   - 最后一段可以稍微多一点

2. 读写分离：读请求走从库，写请求走主库
   - 避免读操作也触发全局锁

3. 本地缓存：热点数据先查缓存，缓存更新时同步到数据库
   - 减少数据库访问频率

3. 监控与告警

需要监控的指标：

1. 全局锁等待次数
2. 全局锁等待超时次数
3. 平均锁等待时间
4. 重试成功次数
5. 重试失败次数

告警规则：

- 锁等待超时率 > 10%：可能存在热点数据
- 平均锁等待时间 > 500ms：锁竞争严重
- 单条记录更新频率 > 1000次/秒：需要分段处理

4. 降级策略

降级策略：

1. 熔断降级：当锁等待超时率超过阈值时，暂时停止该业务
2. 限流降级：对热点商品设置更新频率上限
3. 排队降级：使用分布式队列，将更新请求串行化处理

5. 代码优化示例

// 使用重试注解
@GlobalTransactional
@GlobalLockRetry(maxRetries = 3, initialDelay = 100, maxDelay = 1000)
public void deductStock(Long productId, Integer quantity) {
    // 查询库存
    Stock stock = stockRepository.findByProductId(productId);
    
    // 校验库存
    if (stock.getQuantity() < quantity) {
        throw new BusinessException("库存不足");
    }
    
    // 扣减库存
    stock.setQuantity(stock.getQuantity() - quantity);
    stockRepository.save(stock);
}

配置参数建议

# Seata 全局锁优化配置
seata:
  enabled: true
  application-id: ${spring.application.name}
  tx-service-group: ${spring.application.name}-group
  config:
    type: nacos
    nacos:
      server-addr: localhost:8848
      namespace: public
      group: SEATA_GROUP
  registry:
    type: nacos
    nacos:
      server-addr: localhost:8848
      namespace: public
      group: SEATA_GROUP

  # 全局锁重试配置
  lock:
    retry:
      enabled: true
      max-retries: 3
      initial-delay: 100
      max-delay: 1000
      exponential-backoff: true

# 数据源配置
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/example?useSSL=false&serverTimezone=UTC
    username: admin
    password: password
    driver-class-name: com.mysql.cj.jdbc.Driver

效果对比

总结

Seata 全局锁等待优化的核心原则：

1. 避免无限等待：使用本地重试替代无限阻塞
2. 指数退避：减少锁竞争，给锁持有者足够时间完成
3. 快速失败：超过重试次数后立即返回，释放线程资源
4. 热点隔离：对热点数据进行分段处理，分散锁竞争
5. 监控告警：及时发现锁竞争问题，提前优化

记住：分布式事务不是银弹。在高并发场景下，尽量减少分布式事务的使用，优先考虑最终一致性方案。

源码获取

文章已同步至小程序博客栏目，需要源码的请关注小程序博客。

公众号：服务端技术精选

小程序码：