先kan一组真实的生产数据。

一个有1000家门店的连锁企业，订货系统下单接口的峰值TPS是20。一个有2亿用户的平台，大促期间下单接口的TPS是2000。同一个平台的商品系统，整个域的峰值QPS是70万，分摊到单台机器大约3万多。

大多数系统的实际并发量，比你想象中低得多。

这组数据抛出来hen多人的第一反应是：那我们系统TPS才个位数，是不是不用考虑并发了？

这个想法，每年dou在制造线上事故。

行业里经常把两件事搅在一起说：一件是「高并发架构」，另一件是「并发控制」。

高并发架构解决的是性Neng问题：系统Neng不Neng扛住大流量。缓存、分库分表、读写反分离、异步削峰，这些技术的目的是让系统在大流量下不崩溃。流量不大的系统，确实不需要急着上这些东西。

并发控制解决的是正确性问题：多个请求同时操作同一份数据，结果对不对。锁、事务隔离级别、幂等设计，这些技术的目的是保证数据不出错。

这两件事的驱动力完全不同。高并发架构取决于流量大小，并发控制取决于「有没有两个请求可Neng同时改同一份数据」。

一个TPS只有20的系统，Ru果两个请求在同一毫秒内修改了同一条记录，数据照样会错。并发控制保护的是数据正确性，跟TPS是20还是20万没关系。

有人可Neng会说：TPS才20，两个请求同时到达的概率极低，实际不太会出问题。

这个想法hen危险。概率低不等于不会发生。线上事故有个规律：小概率事件一定会发生，而且往往在你Zui不方便处理的时候发生。业务规则被打破、数据被写坏、资金出现差异，排查一次这种问题花的时间，远超提前写几行锁代码的成本。

场景是这样的：一个连锁企业的订货系统，业务规定每家门店每天只Neng提交一张订货单。1000家门店，TPS峰值20，分到单个门店几乎没有并发。

问题出在「几乎」两个字上。

门店A有两个店员，张三和李四，dou有下单权限。某天下午两点，张三在电脑上点了提交，李四在手机上也点了提交。两个请求间隔不到1秒。

代码里的逻辑通常长这样：先查今天有没有订单，没有就插入。

// 查询今天是否Yi下单
Order existing = orderMapper.selectByStoreAndDate;
if  {
    throw new BusinessException;
}
// 插入新订单
orderMapper.insert;

两个请求几乎同时执行到查询那一步，dou查到「今天没单」，然后dou走到插入逻辑，两张订单dou写进去了。一天只Neng下一单的业务规则，就这么被打破了。

这跟TPS高不高没关系。只要两个请求的执行时间窗口有重叠，问题就会出现。

有人会想到用数据库唯一索引来兜底：给门店ID + 日期建一个唯一索引，第二条插入自然会报错。唯一索引确实Neng防住。

真实业务里下单往往不只是往一张表插一条记录。可Neng还涉及校验库存、锁定配送额度、生成物流预约单等多步操作。唯一索引只Neng保证单表单字段组合的唯一性，保证不了一串业务操作的互斥执行。

这种场景需要的是分布式锁。用Redis的SET命令带NX和EX参数，在业务逻辑执行前获取锁，执行完释放锁。

// 锁的key按门店ID+日期粒度
String lockKey = "order:lock:" + storeId + ":" + today;
// 尝试获取锁，超时时间30秒
Boolean acquired = redisTemplate.opsForValue
    .setIfAbsent;
if  {
    throw new BusinessException;
}
try {
    // 查询今天是否Yi下单
    Order existing = orderMapper.selectByStoreAndDate;
    if  {
        throw new BusinessException;
    }
    // 执行完整的下单逻辑
    orderMapper.insert;
} finally {
    // 释放锁前确认是自己持有的
    if .get)) {
        redisTemplate.delete;
    }
}

锁的粒度选在门店ID + 日期这一层，不同门店之间互不影响。释放锁的时候要校验requestId，防止一种情况：A请求的锁超时自动释放了B请求拿到了新锁，A执行完把B的锁给删了。

这里的释放锁操作不是原子的，严格场景下应该用Lua脚本保证原子性。在门店下单这种TPS极低的场景，概率Yi经hen小了但Ru果你的团队有规范要求，用Lua脚本是geng稳妥的Zuo法。

这段代码加上也就多了十几行。不加的话，一旦出了重复订单，排查数据、通知门店、人工干预，花的时间远超写这几行代码。

商品库存100件，两个用户同时下单各买1件，扣完应该剩98件。

不Zuo任何并发保护的代码：

// 查询当前库存
int stock = goodsMapper.selectStock;
if  {
    throw new BusinessException;
}
// 扣减库存
goodsMapper.updateStock;

两个请求同时读到库存是100，各自算出100-=1，两次UPDATEdou把库存写成了99。卖出了2件，库存只减了1。

这个问题在并发量为2的时候就Neng触发。

这种场景跟门店下单不太一样。门店下单是互斥操作，同一时间只Neng有一个请求通过。库存扣减是竞争操作，多个请求douKe以扣，只是结果不Neng算错。

用分布式锁也Neng解决，把所有扣减请求排成队，一个一个来。代价是同一商品的所有下单请求变成了串行执行，在库存充足的正常情况下这种排队完全没必要。

乐观锁geng适合这种「冲突概率低，但必须保证正确」的场景。

实现方式是给库存表加一个version字段，每次geng新的时候把当前version带上：

UPDATE goods
SET stock = stock - 1, version = version + 1
WHERE id = #{goodsId} AND version = #{currentVersion} AND stock>= #{quantity}

Ru果两个请求同时读到version=1，先执行的那个geng新成功，version变成2。后执行的那个发现versionYi经不是1了UPDATE影响行数为0，表示这次扣减没生效。

geng新失败的请求需要重试：重新查一次Zui新的库存和version，再尝试扣减。通常重试2到3次就够了因为在库存充足的情况下冲突概率本来就低。

int maxRetry = 3;
for  {
    Goods goods = goodsMapper.selectById;
    if  

// 按商品ID粒度加锁，不同商品之间互不影响
private final Map lockMap = new ConcurrentHashMap<>;
public Goods getGoods {
    // 先查本地缓存
    Goods goods = localCache.get;
    if  {
        return goods;
    }
    Object lock = lockMap.computeIfAbsent);
    synchronized  {
        // 拿到锁之后再查一次缓存，可NengYi经被前一个请求加载好了
        goods = localCache.get;
        if  {
            return goods;
        }
        // 缓存确实没有，查数据库并回填
        goods = goodsMapper.selectById;
        localCache.put;
    }
    return goods;
}