高并发场景下有限座位的活动预订多请求该如何处理？

1. 基于乐观锁的库存预扣方案 #

• 无需对活动行加排他锁，在活动表新增available_seats（剩余可用座位）字段，扣减库存时执行带条件的UPDATE语句：

  UPDATE event SET available_seats = available_seats - 1 WHERE event_id = ? AND available_seats > 0
  

• 直接通过该语句的受影响行数判断扣减结果：受影响行数为1则代表抢到座位，后续再执行参与者信息插入等逻辑；受影响行数为0则直接返回库存不足，全程无事务等待，并发性能比排他锁高2-3个数量级，完全可支撑数百级并发请求。
• 若业务需要支持订单超时取消，可额外增加预扣库存过期时间字段，异步回收超时未支付的库存即可。

2. 分布式内存库存分片方案 #

• 如果后续并发量级会上涨到数千甚至更高，可将10K座位拆分为N个库存分片，提前存储在Redis等内存数据库中，比如10个分片每个存储1000个座位。
• 请求到达时按用户ID哈希路由到对应分片执行库存扣减，扣减成功直接返回，单Redis分片的QPS可达10W+，完全无等待延迟。
• 分片路由时如果当前分片库存为0，可自动遍历其他有库存的分片，避免库存碎片化问题。

3. 本地队列+同步等待机制 #

• 如果需要严格控制请求处理顺序同时满足同步返回要求，无需使用全局FIFO队列，改用网关层本地队列+短轮询等待的方式：
• 每个网关实例接收请求后放入本地队列，后台固定数量的工作线程从队列取请求执行库存校验和扣减逻辑，用户请求同步等待最多3s（可自行配置），处理完成后直接返回结果给用户，既不会出现行锁导致的大面积超时，也能满足同步响应的要求。
• 该方案还可加入请求过载保护，队列长度超过阈值时直接返回活动火爆请稍后重试，避免系统被打垮。

方案选型建议 #

• 数百并发量级直接使用第一种乐观锁方案即可，改造成本最低，不需要引入额外中间件，稳定性最高；
• 如果后续有更高并发预期，可叠加第二种Redis库存分片方案；
• 如果有严格的请求顺序处理要求，选择第三种本地队列方案。

内容的提问来源于stack exchange，提问作者Dhairya Verma