一、并发问题的本质与常见误区

当两个事务同时修改同一数据时，若缺乏有效控制机制，会导致数据不一致的经典问题：

• 超卖现象：库存扣减时出现负数
• 脏读问题：读取到未提交的中间状态
• 不可重复读：同一事务内多次查询结果不一致
• 幻读问题：其他事务插入新记录导致统计偏差

典型错误案例：某电商系统采用以下库存扣减逻辑：

@Transactional
public void deductStock(Long productId) {
    Product product = productDao.selectById(productId);
    if (product.getStock() > 0) {
        product.setStock(product.getStock() - 1);
        productDao.update(product);
    }
}

该代码在单线程环境下看似正常，但在高并发场景下会出现以下问题：

1. 事务A查询库存=10
2. 事务B查询库存=10
3. 事务A扣减库存至9
4. 事务B扣减库存至9（实际应为8）

二、单机环境下的SQL级解决方案

1. 数据库原生事务隔离

通过设置合理的事务隔离级别可解决大部分问题：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- 或
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

不同隔离级别的特性对比：
| 级别 | 脏读 | 不可重复读 | 幻读 |
|———————|———|——————|———|
| READ UNCOMMITTED | ❌ | ❌ | ❌ |
| READ COMMITTED | ✅ | ❌ | ❌ |
| REPEATABLE READ | ✅ | ✅ | ❌* |
| SERIALIZABLE | ✅ | ✅ | ✅ |

*注：主流数据库通过MVCC或多版本控制实现REPEATABLE READ下的幻读防护

2. 原子性操作实现

使用数据库原生原子操作是最可靠的解决方案：

-- MySQL示例
UPDATE products 
SET stock = stock - 1 
WHERE product_id = 123 AND stock >= 1;

该SQL的三大优势：

1. 单条语句构成原子操作
2. 条件判断与更新合并执行
3. 返回影响行数可判断操作是否成功

3. 乐观锁与悲观锁

乐观锁实现方案

-- 添加version字段
UPDATE products 
SET stock = stock - 1, version = version + 1 
WHERE product_id = 123 AND version = 5;

适用场景：

• 冲突概率低于10%
• 读多写少场景
• 要求高吞吐量

悲观锁实现方案

-- 使用SELECT FOR UPDATE
BEGIN;
SELECT * FROM products WHERE product_id = 123 FOR UPDATE;
-- 业务逻辑处理
UPDATE products SET stock = stock - 1 WHERE product_id = 123;
COMMIT;

适用场景：

• 冲突概率高于30%
• 写操作密集
• 允许较低吞吐量

三、分布式环境下的扩展方案

1. 分布式锁实现

基于Redis的RedLock算法

// 获取锁
String lockKey = "product_lock_" + productId;
boolean locked = redisTemplate.opsForValue().setIfAbsent(
    lockKey, 
    "locked", 
    30, 
    TimeUnit.SECONDS
);
// 释放锁
if (locked) {
    try {
        // 业务逻辑
    } finally {
        redisTemplate.delete(lockKey);
    }
}

关键注意事项：

1. 锁过期时间需大于业务执行时间
2. 需处理锁续期问题
3. 避免死锁情况发生

2. 消息队列解耦

典型架构设计：

[用户请求] → [API服务] → [消息队列] → [库存服务]
                     ↑
               [补偿队列]

优势分析：

• 异步处理提高系统吞吐量
• 消息持久化保证数据可靠性
• 死信队列处理失败消息

3. 分库分表策略

水平分表设计

-- 按商品ID哈希分表
CREATE TABLE product_stock_0 (
    product_id BIGINT PRIMARY KEY,
    stock INT NOT NULL
);
CREATE TABLE product_stock_1 (
    -- 同上
);

路由算法示例：

public String getTableName(Long productId) {
    int tableIndex = (productId.hashCode() & Integer.MAX_VALUE) % 2;
    return "product_stock_" + tableIndex;
}

四、最佳实践与性能优化

1. 监控指标体系

关键监控项：

• 库存冲突率：冲突事务/总事务数
• 锁等待时间：平均/最大等待时长
• 队列积压量：未处理消息数量
• 操作成功率：成功事务/总事务数

2. 降级预案设计

三级降级策略：

1. 流量削峰：通过限流算法控制请求速率
2. 异步处理：将非实时操作转为异步
3. 服务降级：关闭非核心功能保证主流程

3. 测试验证方法

并发测试方案：

// 使用CountDownLatch模拟并发
CountDownLatch latch = new CountDownLatch(100);
for (int i = 0; i < 100; i++) {
    new Thread(() -> {
        try {
            latch.await();
            // 执行库存扣减
        } catch (Exception e) {
            e.printStackTrace();
        }
    }).start();
}

测试重点验证：

• 最终库存准确性
• 系统吞吐量指标
• 错误处理机制

五、典型场景解决方案

1. 秒杀系统设计

核心策略：

1. 库存预热：提前加载到缓存
2. 队列削峰：所有请求先入队列
3. 异步扣减：通过消息队列处理
4. 库存校验：最终一致性检查

2. 分布式事务处理

SAGA模式实现示例：

1. 预扣减库存
2. 创建订单
3. 支付处理
   ↓
   任一环节失败：
   1. 回滚支付
   2. 取消订单
   3. 恢复库存

3. 多系统数据同步

通过事件溯源模式实现：

[库存服务] → [事件总线] → [订单服务]
                     ↓
               [物流服务]

每个服务维护自己的数据副本，通过事件流保持最终一致。

结语

数据库并发控制是系统架构设计的核心挑战之一。从单机环境的SQL优化到分布式架构的复杂协调，开发者需要根据具体场景选择合适方案。建议遵循”先简单后复杂”的原则：优先尝试数据库原生解决方案，在确实需要时再引入分布式组件。通过完善的监控体系和降级预案，可构建既高效又可靠的并发控制系统。