分布式并发更新指南：乐观锁、悲观锁、Redis 锁与消息队列

并发更新全攻略：从“超卖”到“稳如老狗”的五大解决方案

并发更新是后端开发中最容易“掉坑”的地方之一，尤其是在高并发的业务场景下。处理不好，轻则数据轻微不准，重则超卖、资金损失等严重问题。

别慌，本文为你梳理 5种经典解决方案 —— 从易到难，从单机到分布式，帮你把并发更新安排得“稳如老狗”！

一、问题复现：经典的“超卖”场景

假设我们有一个商品库存表 product：

| id | name | stock | | :- | :-------- | :---- | | 1 | iPhone 14 | 100 |

并发更新的典型坑是这样的：

@Transactional public void deductStock(Long productId) { // 1. 查询商品 Product product = productMapper.selectById(productId); // 2. 判断库存 if (product != null && product.getStock() > 0) { // 3. 更新库存 (stock - 1) product.setStock(product.getStock() - 1); productMapper.updateById(product); } }

问题所在：在 @Transactional 事务中，“查询”和“更新”是两步操作。如果多个线程同时执行到第1步，它们可能都读到库存为100，然后都去执行减1操作，最终库存可能变成99，而不是正确的98。这就是 丢失更新。

二、五大解决方案<