并发控制

引言 “并发是计算机科学中最难的问题之一,因为它涉及时间、顺序和不确定性。” —— Leslie Lamport 在前两篇文章中,我们了解了MySQL如何通过索引实现快速查询,如何通过WAL日志保证数据持久化。但还有一个核心问题没有解决: 如何在高并发场景下保证数据一致性? 想象这样的场景: 双11零点,100万用户同时抢购一件库存只有10个的商品 每个用户都执行: 1. 读取库存 → 10 2. 判断库存足够 → 是 3. 扣减库存 → 库存 - 1 4. 创建订单 结果:卖出了100万件,但库存只扣了10个 💥 这就是并发控制的核心难题:如何让多个并发事务互不干扰,同时保证数据一致性? 今天,我们从第一性原理出发,深度剖析MySQL的并发控制机制: 无控制 → 锁机制 → MVCC → 隔离级别 → 死锁处理 混乱 串行化 读写分离 灵活平衡 自动恢复 ❌ ⚠️ ✅ ✅ ✅ 我们还将手写MVCC核心逻辑,彻底理解MySQL如何实现读写不阻塞。 一、问题的起点:并发导致的数据混乱 让我们从一个最经典的并发问题开始:电商库存扣减。 1.1 场景:秒杀商品超卖问题 需求: 商品:iPhone 16 Pro Max（库存10件） 活动:双11零点秒杀,原价9999元,秒杀价1元 预期:10个用户抢到,其余用户提示"已抢完" 无并发控制的实现: /** * 秒杀服务（无并发控制） */ @Service public class SeckillService { @Autowired private ProductMapper productMapper; @Autowired private OrderMapper orderMapper; /** * 秒杀下单（存在并发问题） */ public boolean seckill(Long productId, Long userId) { // 1. 读取库存 Product product = productMapper.selectById(productId); int stock = product.getStock(); // 2. 判断库存是否足够 if (stock <= 0) { return false; // 库存不足 } // 3. 扣减库存 product.setStock(stock - 1); productMapper.updateById(product); // 4. 创建订单 Order order = new Order(); order.setUserId(userId); order.setProductId(productId); order.setAmount(1.00); // 秒杀价1元 orderMapper.insert(order); return true; } } 并发测试: ...

引言 “并发是计算机科学中最难的问题之一,因为它涉及时间、顺序和不确定性。” —— Leslie Lamport 在前两篇文章中,我们了解了MySQL如何通过索引实现快速查询,如何通过WAL日志保证数据持久化。但还有一个核心问题没有解决: 如何在高并发场景下保证数据一致性? 想象这样的场景: 双11零点,100万用户同时抢购一件库存只有10个的商品 每个用户都执行: 1. 读取库存 → 10 2. 判断库存足够 → 是 3. 扣减库存 → 库存 - 1 4. 创建订单 结果:卖出了100万件,但库存只扣了10个 💥 这就是并发控制的核心难题:如何让多个并发事务互不干扰,同时保证数据一致性? 今天,我们从第一性原理出发,深度剖析MySQL的并发控制机制: 无控制 → 锁机制 → MVCC → 隔离级别 → 死锁处理 混乱 串行化 读写分离 灵活平衡 自动恢复 ❌ ⚠️ ✅ ✅ ✅ 我们还将手写MVCC核心逻辑,彻底理解MySQL如何实现读写不阻塞。 一、问题的起点:并发导致的数据混乱 让我们从一个最经典的并发问题开始:电商库存扣减。 1.1 场景:秒杀商品超卖问题 需求: 商品:iPhone 16 Pro Max（库存10件） 活动:双11零点秒杀,原价9999元,秒杀价1元 预期:10个用户抢到,其余用户提示"已抢完" 无并发控制的实现: /** * 秒杀服务（无并发控制） */ @Service public class SeckillService { @Autowired private ProductMapper productMapper; @Autowired private OrderMapper orderMapper; /** * 秒杀下单（存在并发问题） */ public boolean seckill(Long productId, Long userId) { // 1. 读取库存 Product product = productMapper.selectById(productId); int stock = product.getStock(); // 2. 判断库存是否足够 if (stock <= 0) { return false; // 库存不足 } // 3. 扣减库存 product.setStock(stock - 1); productMapper.updateById(product); // 4. 创建订单 Order order = new Order(); order.setUserId(userId); order.setProductId(productId); order.setAmount(1.00); // 秒杀价1元 orderMapper.insert(order); return true; } } 并发测试: ...

实战案例概览 案例 核心问题 解决方案 难点 转账业务 数据一致性、死锁 固定加锁顺序、悲观锁 多账户并发转账 秒杀抢购 超卖、高并发 乐观锁 + 限流 10000人抢100件商品 订单支付 重复支付、幂等性 悲观锁 + 唯一约束 防止重复扣款 红包发放 余额不足、公平性 悲观锁 + 事务隔离 1个红包被多人抢 积分扣减 负数积分 乐观锁 + 余额检查 并发扣减积分 案例1：转账业务 需求 用户A向用户B转账100元，要求： 余额不能为负数 转账过程中不能被打断 防止死锁 方案1：基础实现（有死锁风险） -- ❌ 可能死锁 -- 事务A：A向B转100 START TRANSACTION; UPDATE account SET balance = balance - 100 WHERE user_id = 'A'; -- 锁A UPDATE account SET balance = balance + 100 WHERE user_id = 'B'; -- 等待锁B COMMIT; -- 事务B：B向A转50（并发执行） START TRANSACTION; UPDATE account SET balance = balance - 50 WHERE user_id = 'B'; -- 锁B UPDATE account SET balance = balance + 50 WHERE user_id = 'A'; -- 等待锁A（死锁！） COMMIT; 方案2：固定加锁顺序（推荐） -- ✅ 避免死锁：按user_id升序加锁 -- 转账函数（伪代码） FUNCTION transfer(from_user, to_user, amount): -- 1. 固定加锁顺序（按user_id升序） first_user = MIN(from_user, to_user) second_user = MAX(from_user, to_user) START TRANSACTION; -- 2. 按顺序锁定账户 SELECT balance FROM account WHERE user_id = first_user FOR UPDATE; SELECT balance FROM account WHERE user_id = second_user FOR UPDATE; -- 3. 检查余额 IF from_user.balance < amount THEN ROLLBACK; RETURN "余额不足"; END IF; -- 4. 扣款和到账 UPDATE account SET balance = balance - amount WHERE user_id = from_user; UPDATE account SET balance = balance + amount WHERE user_id = to_user; COMMIT; RETURN "转账成功"; END FUNCTION; 方案3：Java实现（完整代码） @Service public class TransferService { @Autowired private AccountMapper accountMapper; @Transactional(rollbackFor = Exception.class) public void transfer(String fromUser, String toUser, BigDecimal amount) { // 1. 固定加锁顺序（避免死锁） String firstUser = fromUser.compareTo(toUser) < 0 ? fromUser : toUser; String secondUser = fromUser.compareTo(toUser) < 0 ? toUser : fromUser; // 2. 按顺序锁定账户（悲观锁） Account first = accountMapper.selectForUpdate(firstUser); Account second = accountMapper.selectForUpdate(secondUser); // 3. 检查余额 Account fromAccount = fromUser.equals(firstUser) ? first : second; if (fromAccount.getBalance().compareTo(amount) < 0) { throw new BusinessException("余额不足"); } // 4. 扣款和到账 accountMapper.updateBalance(fromUser, amount.negate()); // 扣款 accountMapper.updateBalance(toUser, amount); // 到账 // 5. 记录流水（可选） recordTransferLog(fromUser, toUser, amount); } } <!-- MyBatis Mapper --> <select id="selectForUpdate" resultType="Account"> SELECT * FROM account WHERE user_id = #{userId} FOR UPDATE </select> <update id="updateBalance"> UPDATE account SET balance = balance + #{amount} WHERE user_id = #{userId} </update> 案例2：秒杀抢购 需求 10000个用户抢购100件商品，要求： ...

乐观锁 vs 悲观锁 核心思想 类型 核心思想 锁机制 冲突处理 适用场景 悲观锁 先加锁，再操作（悲观：总会冲突） 数据库锁（X锁、S锁） 阻塞等待 冲突频繁 乐观锁 先操作，提交时检查（乐观：很少冲突） 版本号、时间戳 重试或放弃 冲突少 1. 悲观锁（Pessimistic Lock） 定义 假设冲突一定会发生，每次读取数据前先加锁，其他事务无法修改数据。 实现方式 方式1：排他锁（FOR UPDATE） -- 加排他锁 START TRANSACTION; SELECT * FROM account WHERE id = 1 FOR UPDATE; -- 加X锁，其他事务阻塞 -- 修改数据 UPDATE account SET balance = 900 WHERE id = 1; COMMIT; -- 释放锁 方式2：共享锁（LOCK IN SHARE MODE） -- 加共享锁 START TRANSACTION; SELECT * FROM account WHERE id = 1 LOCK IN SHARE MODE; -- 加S锁，其他事务可读但不可写 -- 读取后再更新 UPDATE account SET balance = 900 WHERE id = 1; COMMIT; 应用场景 场景1：库存扣减（防止超卖） -- 秒杀场景：10000个用户抢100件商品 START TRANSACTION; -- 1. 加锁查询库存 SELECT stock FROM product WHERE id = 1001 FOR UPDATE; -- 悲观锁 -- stock = 100 -- 2. 检查库存 IF stock >= 1 THEN -- 3. 扣减库存 UPDATE product SET stock = stock - 1 WHERE id = 1001; -- 4. 创建订单 INSERT INTO orders (user_id, product_id) VALUES (123, 1001); COMMIT; ELSE ROLLBACK; -- 库存不足 END IF; 场景2：转账业务 ...

MySQL锁分类 按锁粒度分类 全局锁（Global Lock） └─ FTWRL（Flush Tables With Read Lock） 表锁（Table Lock） ├─ 表级锁 ├─ 元数据锁（MDL Lock） └─ 意向锁（Intention Lock） 行锁（Row Lock） ├─ 记录锁（Record Lock） ├─ 间隙锁（Gap Lock） └─ Next-Key Lock（Record + Gap） 按锁模式分类 锁模式 英文名 兼容性 应用场景 共享锁（S锁） Shared Lock 读读兼容，读写互斥 SELECT … LOCK IN SHARE MODE 排他锁（X锁） Exclusive Lock 完全互斥 UPDATE、DELETE、SELECT … FOR UPDATE 1. 全局锁（Global Lock） 定义 锁住整个数据库实例，只读不可写。 命令 -- 加全局读锁 FLUSH TABLES WITH READ LOCK; -- 简称FTWRL -- 此时其他会话： SELECT * FROM account WHERE id = 1; -- ✅ 可以读 UPDATE account SET balance = 900 WHERE id = 1; -- ❌ 阻塞 INSERT INTO account VALUES (2, 'B', 500); -- ❌ 阻塞 -- 释放锁 UNLOCK TABLES; 应用场景 全库逻辑备份（保证数据一致性）： ...

什么是MVCC？ MVCC（Multi-Version Concurrency Control，多版本并发控制） 是InnoDB实现高并发的核心机制。 核心思想： 每行数据有多个版本 读操作读取快照版本（不加锁） 写操作创建新版本（加锁） 读写不冲突，提高并发性能 适用隔离级别： ✅ READ COMMITTED ✅ REPEATABLE READ ❌ READ UNCOMMITTED（无需MVCC） ❌ SERIALIZABLE（完全加锁） MVCC的实现机制 1. 隐藏字段 InnoDB为每行数据添加三个隐藏字段： 字段名 长度 说明 DB_TRX_ID 6字节 最后修改该行的事务ID DB_ROLL_PTR 7字节 回滚指针，指向undo log DB_ROW_ID 6字节 隐藏主键（无主键时自动生成） -- 实际存储的行数据（用户不可见） ┌────┬──────┬─────────┬────────────┬─────────────┬────────────┐ │ id │ name │ balance │ DB_TRX_ID │ DB_ROLL_PTR │ DB_ROW_ID │ ├────┼──────┼─────────┼────────────┼─────────────┼────────────┤ │ 1 │ A │ 1000 │ 100 │ 0x7FA8... │ 1 │ └────┴──────┴─────────┴────────────┴─────────────┴────────────┘ 2. undo log版本链 每次修改数据，旧版本保存在undo log，形成版本链。 -- 初始数据 INSERT INTO account (id, name, balance) VALUES (1, 'A', 1000); -- DB_TRX_ID = 100 -- 事务101：修改余额 UPDATE account SET balance = 900 WHERE id = 1; -- DB_TRX_ID = 101，旧版本保存到undo log -- 事务102：再次修改 UPDATE account SET balance = 800 WHERE id = 1; -- DB_TRX_ID = 102，旧版本保存到undo log 版本链结构： ...

为什么需要隔离级别？ 并发事务可能产生三大问题： 脏读（Dirty Read）：读到未提交的数据 不可重复读（Non-Repeatable Read）：同一查询两次结果不同 幻读（Phantom Read）：范围查询两次结果不同 隔离级别就是用来控制在多大程度上解决这些问题。 四种隔离级别 级别对比表 隔离级别 脏读 不可重复读 幻读 性能 应用场景 READ UNCOMMITTED（读未提交） ❌ 会 ❌ 会 ❌ 会 ⭐⭐⭐⭐ 几乎不用 READ COMMITTED（读已提交） ✅ 避免 ❌ 会 ❌ 会 ⭐⭐⭐ Oracle/PostgreSQL默认 REPEATABLE READ（可重复读） ✅ 避免 ✅ 避免 ⚠️ 部分避免 ⭐⭐ MySQL默认（推荐） SERIALIZABLE（串行化） ✅ 避免 ✅ 避免 ✅ 避免 ⭐ 严格一致性要求 1. READ UNCOMMITTED（读未提交） 特点：事务可以读取其他事务未提交的数据（脏读）。 演示：脏读问题 -- 设置隔离级别 SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; -- 事务A START TRANSACTION; SELECT balance FROM account WHERE user_id = 'A'; -- 读到1000 -- 事务B（并发执行） START TRANSACTION; UPDATE account SET balance = 500 WHERE user_id = 'A'; -- 未提交 -- 此时事务A再次查询 -- 事务A SELECT balance FROM account WHERE user_id = 'A'; -- 读到500（脏读！） COMMIT; -- 事务B ROLLBACK; -- 回滚，余额恢复到1000 问题：事务A读到了事务B未提交的数据（500），但事务B最终回滚了，导致数据不一致。 ...