一、并发问题的本质：从表象到根源

当两个用户同时操作同一条库存记录时，系统可能面临三种典型风险：

超卖现象：两个事务同时读取库存为10，均完成扣减后实际库存变为8
脏读问题：事务A修改未提交的数据被事务B读取
更新丢失：事务B覆盖了事务A的修改结果

这些问题的根源在于数据库的隔离级别设置与事务处理机制的配合不当。主流关系型数据库（如MySQL InnoDB）默认采用REPEATABLE READ隔离级别，虽然能避免脏读，但无法完全解决并发更新问题。

二、SQL层面的并发控制方案

2.1 原子性操作的实现

-- 错误示范：非原子操作
UPDATE products 
SET stock = stock - 1 
WHERE id = 123 AND stock > 0;
-- 正确写法：条件更新+原子操作
UPDATE products 
SET stock = stock - 1 
WHERE id = 123 AND stock >= 1;

关键点在于将业务逻辑（库存检查）内嵌到SQL语句中，利用数据库的原子性特性确保操作的完整性。这种写法相比先查询后更新的模式，减少了网络往返和上下文切换的开销。

2.2 乐观锁与悲观锁的选择

乐观锁实现方案

-- 添加版本号字段
ALTER TABLE products ADD COLUMN version INT DEFAULT 0;
-- 更新时校验版本
UPDATE products 
SET stock = stock - 1, version = version + 1 
WHERE id = 123 AND version = 5;

乐观锁适用于读多写少的场景，通过CAS（Compare-And-Swap）机制实现。当更新影响行数为0时，表示数据已被其他事务修改，需要应用层重试。

悲观锁使用场景

-- 显式加锁（MySQL示例）
START TRANSACTION;
SELECT * FROM products WHERE id = 123 FOR UPDATE;
-- 业务处理...
UPDATE products SET stock = stock - 1 WHERE id = 123;
COMMIT;

悲观锁适合写密集型场景，但需注意：

锁的粒度要尽可能小（行锁优于表锁）
事务持续时间要尽量短
避免死锁（按固定顺序访问表）

2.3 事务隔离级别的优化

不同隔离级别的特性对比：
| 级别 | 脏读 | 不可重复读 | 幻读 | 适用场景 |
|———————|———|——————|———|————————————|
| READ UNCOMMITTED | ❌ | ❌ | ❌ | 极高性能要求的特殊场景 |
| READ COMMITTED | ✔️ | ❌ | ❌ | 大多数业务系统 |
| REPEATABLE READ | ✔️ | ✔️ | ❌ | 需要严格一致性的场景 |
| SERIALIZABLE | ✔️ | ✔️ | ✔️ | 金融交易等极端场景 |

建议根据业务特点选择：

电商库存：REPEATABLE READ + 条件更新
财务系统：SERIALIZABLE隔离级别
评论系统：READ COMMITTED足够

三、高并发场景的优化实践

3.1 分库分表策略

当单表数据量超过500万行时，考虑垂直/水平拆分：

-- 按用户ID哈希分表示例
CREATE TABLE products_0 (...);
CREATE TABLE products_1 (...);
-- 路由逻辑
$tableSuffix = $userId % 2;
$sql = "UPDATE products_$tableSuffix SET ...";

分表后需注意：

跨分片事务处理（建议使用最终一致性方案）
全局唯一ID生成（雪花算法等）
查询路由策略

3.2 异步化处理架构

对于非实时性要求高的操作，可采用消息队列解耦：

sequenceDiagram
    用户->>订单服务: 提交订单
    订单服务->>库存服务: 发送扣减消息(MQ)
    库存服务->>数据库: 条件更新
    库存服务-->>订单服务: 异步通知结果

这种架构的优点：

削峰填谷，应对突发流量
系统解耦，提高可用性
便于扩展和维护

3.3 缓存策略的合理应用

// 双删策略示例
public void updateStock(Long productId) {
    // 1. 先删除缓存
    cache.del(productId);
    // 2. 更新数据库
    db.updateStock(productId);
    // 3. 延迟删除缓存（防止脏数据）
    new Thread(() -> {
        Thread.sleep(500);
        cache.del(productId);
    }).start();
}

缓存使用的注意事项：

设置合理的过期时间
避免缓存穿透（布隆过滤器）
防止缓存雪崩（随机过期时间）

四、监控与告警体系构建

4.1 关键指标监控

建议监控以下指标：

数据库连接数使用率
慢查询数量
锁等待超时次数
事务执行时间分布

4.2 异常处理机制

@Retryable(value = {OptimisticLockingFailureException.class}, 
           maxAttempts = 3, 
           backoff = @Backoff(delay = 100))
public void deductStock(Long productId) {
    // 业务逻辑
}

完善的异常处理应包含：

重试机制（指数退避）
熔断降级策略
死锁检测与处理
日志追踪链

五、典型场景解决方案

5.1 秒杀系统设计

用户请求 -> 限流 -> 队列缓冲 -> 异步处理 -> 结果通知

关键技术点：

前端静态化
库存预热
令牌桶算法限流
分布式锁控制最终一致性

5.2 分布式事务方案

对于跨服务的数据一致性，可选择：

TCC模式（Try-Confirm-Cancel）
SAGA模式（长事务解决方案）
本地消息表（最终一致性）

六、最佳实践总结

优先使用数据库原生能力：90%的并发问题可通过优化SQL和事务解决
合理选择隔离级别：根据业务特点权衡性能与一致性
实施渐进式优化：从单表优化到分库分表，从同步到异步
建立完善的监控体系：提前发现潜在问题
设计容错机制：确保系统在异常情况下的可恢复性

在技术选型时，建议遵循”简单优先”原则：先尝试用SQL解决，不行再考虑分布式锁，最后才考虑消息队列等复杂方案。实际开发中，80%的并发问题通过正确的SQL写法+适当的事务隔离级别就能解决，真正需要分布式锁的场景不足20%。

并发场景下的数据库操作：如何优雅解决数据一致性问题？