问题背景

在微服务架构中，分布式事务是一个绕不开的挑战。Seata 作为一款开源的分布式事务解决方案，以其简单易用的特点赢得了广泛的应用。其中，AT 模式由于其无侵入性，成为了很多开发者的首选。然而，在高并发场景下，Seata AT 模式的锁冲突问题逐渐凸显：

• 全局锁等待超时：多个事务同时操作同一数据时，后到的事务需要等待前面的事务释放锁，超过超时时间后会导致事务失败
• 性能下降：锁冲突严重时，系统吞吐量显著下降，响应时间延长
• 死锁风险：在复杂的业务场景中，可能出现死锁，导致系统完全不可用
• 难以定位：锁冲突的原因复杂，难以快速定位和解决

核心概念

Seata AT 模式原理

Seata AT 模式是一种基于数据库本地事务的两阶段提交方案：

1. 第一阶段：业务 SQL 执行前，Seata 会记录数据的原始状态（undo log），然后执行业务 SQL，最后提交本地事务
2. 第二阶段：如果所有分支事务都成功，Seata 会删除 undo log；如果有分支事务失败，Seata 会根据 undo log 回滚数据

全局锁机制

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

• 全局锁：由 Seata Server 管理，用于协调多个事务对同一数据的访问
• 本地锁：由数据库管理，用于保证本地事务的原子性
• 锁冲突：当多个事务同时操作同一数据时，会产生锁冲突

锁冲突产生的原因

1. 热点数据竞争：多个事务同时操作同一数据
2. 事务粒度过大：单个事务操作过多数据，增加锁冲突的概率
3. 锁超时设置不合理：锁等待时间过短，容易导致超时
4. 事务执行时间过长：事务执行时间长，锁持有时间长
5. 并发度过高：系统并发度超过了数据库和 Seata 的处理能力

技术实现

方案架构

我们将实现一个集成了 Seata AT 模式锁冲突优化的 Spring Boot 应用，主要包含以下组件：

• 业务服务：实现具体的业务逻辑
• Seata 配置：配置 Seata 相关参数
• 锁冲突检测：检测和分析锁冲突
• 优化策略：实现各种锁冲突优化策略
• 监控系统：监控锁冲突情况

核心代码实现

1. Seata 配置类

@Configuration
public class SeataConfig {

    @Bean
    public DataSourceProxy dataSourceProxy(DataSource dataSource) {
        return new DataSourceProxy(dataSource);
    }

    @Bean
    public GlobalTransactionScanner globalTransactionScanner() {
        return new GlobalTransactionScanner("order-service", "my-order-group");
    }

    @Bean
    public SqlSessionFactory sqlSessionFactoryBean(DataSourceProxy dataSourceProxy) throws Exception {
        SqlSessionFactoryBean sqlSessionFactoryBean = new SqlSessionFactoryBean();
        sqlSessionFactoryBean.setDataSource(dataSourceProxy);
        return sqlSessionFactoryBean.getObject();
    }
}

2. 业务服务实现

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private AccountService accountService;

    @GlobalTransactional(name = "create-order", timeoutMills = 60000)
    public Order createOrder(OrderDTO orderDTO) {
        // 创建订单
        Order order = new Order();
        order.setUserId(orderDTO.getUserId());
        order.setProductId(orderDTO.getProductId());
        order.setCount(orderDTO.getCount());
        order.setAmount(orderDTO.getAmount());
        order.setStatus(0);
        orderMapper.create(order);

        // 扣减账户余额
        accountService.deduct(orderDTO.getUserId(), orderDTO.getAmount());

        return order;
    }
}

3. 锁冲突优化实现

@Service
public class LockOptimizationService {

    /**
     * 优化方案1：减少事务粒度
     */
    @GlobalTransactional(name = "create-order-optimized", timeoutMills = 30000)
    public Order createOrderOptimized(OrderDTO orderDTO) {
        // 1. 先检查库存（非事务操作）
        checkStock(orderDTO.getProductId(), orderDTO.getCount());

        // 2. 创建订单（事务操作）
        Order order = createOrderInTransaction(orderDTO);

        // 3. 扣减账户余额（事务操作）
        accountService.deduct(orderDTO.getUserId(), orderDTO.getAmount());

        return order;
    }

    /**
     * 优化方案2：使用乐观锁
     */
    @GlobalTransactional(name = "update-order-optimized", timeoutMills = 30000)
    public boolean updateOrderStatus(Long orderId, Integer status) {
        int retryCount = 0;
        while (retryCount < 3) {
            try {
                Order order = orderMapper.selectById(orderId);
                if (order == null) {
                    return false;
                }
                // 使用乐观锁更新
                int result = orderMapper.updateStatusWithVersion(orderId, status, order.getVersion());
                if (result > 0) {
                    return true;
                }
                retryCount++;
                Thread.sleep(100);
            } catch (Exception e) {
                log.error("Update order status failed: {}", e.getMessage());
                retryCount++;
            }
        }
        return false;
    }

    /**
     * 优化方案3：异步处理非核心流程
     */
    @GlobalTransactional(name = "create-order-async", timeoutMills = 30000)
    public Order createOrderWithAsync(OrderDTO orderDTO) {
        // 创建订单
        Order order = createOrderInTransaction(orderDTO);

        // 扣减账户余额
        accountService.deduct(orderDTO.getUserId(), orderDTO.getAmount());

        // 异步处理非核心流程
        asyncService.processNonCoreTasks(order.getId());

        return order;
    }
}

技术架构

系统架构图

┌─────────────────────┐
│   客户端应用         │
└──────────┬──────────┘
           │
┌──────────▼──────────┐
│   订单服务           │
│                     │
│ ┌─────────────────┐ │
│ │ 业务逻辑         │ │
│ ├─────────────────┤ │
│ │ Seata 代理       │ │
│ ├─────────────────┤ │
│ │ 锁冲突优化       │ │
│ └─────────────────┘ │
└──────────┬──────────┘
           │
┌──────────▼──────────┐     ┌─────────────────────┐
│   账户服务           │────▶│   Seata Server       │
└─────────────────────┘     └─────────────────────┘
           │
┌──────────▼──────────┐
│   库存服务           │
└─────────────────────┘

工作流程图

1. 事务开始：客户端发起分布式事务请求
2. 资源准备：Seata 开始第一阶段，准备资源
3. 业务执行：执行业务逻辑，操作数据库
4. 锁检测：检测和处理锁冲突
5. 事务提交/回滚：根据执行结果，提交或回滚事务
6. 锁释放：释放全局锁和本地锁

配置说明

核心配置

数据源配置

最佳实践

1. 业务层面优化

• 减少事务粒度：将大事务拆分为多个小事务，减少锁持有时间
• 避免热点数据：设计合理的数据模型，避免单点数据竞争
• 异步处理：将非核心流程异步处理，减少事务执行时间
• 合理设计业务流程：优化业务流程，减少不必要的事务操作
• 使用幂等设计：确保操作的幂等性，减少重试带来的锁冲突

2. 配置层面优化

• 合理设置锁超时时间：根据业务场景设置合适的锁超时时间
• 调整锁重试策略：增加锁重试次数，减少因短暂冲突导致的失败
• 优化数据库连接池：配置合理的连接池大小，避免连接不足
• 调整事务隔离级别：根据业务需求选择合适的事务隔离级别
• 配置合理的线程池：调整服务线程池大小，避免线程资源耗尽

3. 代码层面优化

• 使用乐观锁：对于并发更新场景，使用乐观锁替代悲观锁
• 批量操作优化：对于批量操作，采用分批处理，减少锁冲突
• 合理使用索引：为频繁查询的字段创建索引，减少锁持有时间
• 避免长事务：尽量缩短事务执行时间，避免长时间持有锁
• 使用缓存：对于读多写少的场景，使用缓存减少数据库访问

4. 架构层面优化

• 引入缓存：使用 Redis 等缓存减少数据库访问
• 读写分离：实现读写分离，减少写操作对读操作的影响
• 分库分表：对热点数据进行分库分表，减少单表并发压力
• 服务拆分：将大服务拆分为小服务，减少事务范围
• 使用消息队列：将同步操作改为异步操作，减少事务耦合

5. 监控与调优

• 实时监控：监控锁冲突情况，及时发现问题
• 性能压测：定期进行性能压测，发现潜在问题
• 日志分析：分析 Seata 日志，定位锁冲突原因
• 动态调优：根据监控数据动态调整配置参数
• 告警机制：设置锁冲突告警，及时处理异常情况

问题排查

常见问题及解决方案

排查步骤

1. 查看日志：分析 Seata 日志和业务日志，定位锁冲突的具体位置
2. 监控指标：查看系统监控指标，了解锁冲突的频率和影响
3. 数据库分析：分析数据库慢查询，定位性能瓶颈
4. 代码审查：审查业务代码，查找可能导致锁冲突的问题
5. 压测验证：通过压测验证优化效果，找出最优配置

调试工具

• Seata 控制台：查看事务状态和锁信息
• 数据库监控：监控数据库锁等待情况
• 应用监控：监控应用性能和线程状态
• 分布式追踪：使用 SkyWalking 等工具追踪分布式事务
• 压测工具：使用 JMeter 等工具进行性能压测

性能测试

测试环境

• 硬件配置：8核16G服务器
• 软件版本：Spring Boot 2.7.15, Seata 1.6.1, MySQL 8.0
• 测试工具：JMeter
• 测试场景：1000并发用户，持续测试10分钟

测试结果

优化效果分析

1. 减少事务粒度：通过拆分大事务，吞吐量提升约100%，响应时间减少约40%
2. 使用乐观锁：通过使用乐观锁替代悲观锁，吞吐量提升约25%，响应时间减少约17%
3. 异步处理：通过异步处理非核心流程，吞吐量提升约20%，响应时间减少约20%
4. 综合优化：通过多种优化手段的组合，吞吐量提升约100%，响应时间减少约33%，错误率降低约90%

代码示例

1. 订单服务实现

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private AccountService accountService;

    @Autowired
    private StockService stockService;

    /**
     * 原始实现 - 可能存在锁冲突
     */
    @GlobalTransactional(name = "create-order", timeoutMills = 60000)
    public Order createOrder(OrderDTO orderDTO) {
        // 创建订单
        Order order = new Order();
        order.setUserId(orderDTO.getUserId());
        order.setProductId(orderDTO.getProductId());
        order.setCount(orderDTO.getCount());
        order.setAmount(orderDTO.getAmount());
        order.setStatus(0);
        orderMapper.create(order);

        // 扣减库存
        stockService.deduct(orderDTO.getProductId(), orderDTO.getCount());

        // 扣减账户余额
        accountService.deduct(orderDTO.getUserId(), orderDTO.getAmount());

        return order;
    }

    /**
     * 优化实现 - 减少锁冲突
     */
    @GlobalTransactional(name = "create-order-optimized", timeoutMills = 30000)
    public Order createOrderOptimized(OrderDTO orderDTO) {
        // 1. 先检查库存（非事务操作）
        boolean hasStock = stockService.checkStock(orderDTO.getProductId(), orderDTO.getCount());
        if (!hasStock) {
            throw new RuntimeException("Insufficient stock");
        }

        // 2. 扣减库存（事务操作）
        stockService.deduct(orderDTO.getProductId(), orderDTO.getCount());

        // 3. 创建订单（事务操作）
        Order order = new Order();
        order.setUserId(orderDTO.getUserId());
        order.setProductId(orderDTO.getProductId());
        order.setCount(orderDTO.getCount());
        order.setAmount(orderDTO.getAmount());
        order.setStatus(0);
        orderMapper.create(order);

        // 4. 扣减账户余额（事务操作）
        accountService.deduct(orderDTO.getUserId(), orderDTO.getAmount());

        return order;
    }
}

2. 库存服务实现

@Service
public class StockService {

    @Autowired
    private StockMapper stockMapper;

    /**
     * 检查库存（非事务操作）
     */
    public boolean checkStock(Long productId, Integer count) {
        Stock stock = stockMapper.selectByProductId(productId);
        return stock != null && stock.getCount() >= count;
    }

    /**
     * 扣减库存（事务操作）
     */
    @GlobalTransactional(name = "deduct-stock", timeoutMills = 30000)
    public void deduct(Long productId, Integer count) {
        int retryCount = 0;
        while (retryCount < 3) {
            try {
                Stock stock = stockMapper.selectByProductId(productId);
                if (stock == null || stock.getCount() < count) {
                    throw new RuntimeException("Insufficient stock");
                }
                // 使用乐观锁更新
                int result = stockMapper.deductWithVersion(productId, count, stock.getVersion());
                if (result > 0) {
                    return;
                }
                retryCount++;
                Thread.sleep(100);
            } catch (Exception e) {
                log.error("Deduct stock failed: {}", e.getMessage());
                retryCount++;
            }
        }
        throw new RuntimeException("Failed to deduct stock after multiple retries");
    }
}

3. 账户服务实现

@Service
public class AccountService {

    @Autowired
    private AccountMapper accountMapper;

    /**
     * 扣减账户余额
     */
    @GlobalTransactional(name = "deduct-account", timeoutMills = 30000)
    public void deduct(Long userId, BigDecimal amount) {
        int retryCount = 0;
        while (retryCount < 3) {
            try {
                Account account = accountMapper.selectByUserId(userId);
                if (account == null || account.getBalance().compareTo(amount) < 0) {
                    throw new RuntimeException("Insufficient balance");
                }
                // 使用乐观锁更新
                int result = accountMapper.deductWithVersion(userId, amount, account.getVersion());
                if (result > 0) {
                    return;
                }
                retryCount++;
                Thread.sleep(100);
            } catch (Exception e) {
                log.error("Deduct account failed: {}", e.getMessage());
                retryCount++;
            }
        }
        throw new RuntimeException("Failed to deduct account after multiple retries");
    }
}

结论

SpringBoot + Seata AT 模式锁冲突优化方案为解决高并发下全局锁等待超时的问题提供了一个完整的解决方案。通过业务层面、配置层面、代码层面和架构层面的综合优化，可以显著减少锁冲突，提升系统性能和稳定性。

本方案不仅可以应用于传统的微服务架构，也可以应用于云原生环境，为分布式事务的可靠运行提供保障。随着微服务架构的广泛应用，分布式事务的重要性将日益凸显，而锁冲突优化将成为提升系统性能的关键因素。

更多技术文章，欢迎关注公众号：服务端技术精选