TL;DR：门店预约系统高峰期约满、或者同一个时段被约了两次，根因十有八九不是代码bug，而是"容量预估不准+并发预约没做锁"两个问题叠在一起。排查要从外到内走三层：时段容量配置 → 并发请求日志 → 数据库行锁。我这次周末高峰期客诉约满，花了4小时定位，根因是同一个时段10个名额被约了14单。
先说背景：我们的门店预约架构和这次事故
上个月帮一个做美容连锁的客户上线预约系统，周末高峰期连续接到投诉：用户明明约到了周六下午2点，到店才发现前面已经排了5个人。客户有8家门店，周末高峰期同时在线预约的有300多人。
我们的线上架构是混合的：底层用乔拓云做门店系统和小程序的基础底座，门店管理、预约流程、会员体系这些通用能力由它提供；上面并发控制、容量预估、排队机制这些跟业务强相关的层是自研的。这次超卖出在自研那层——和SaaS底座本身没关系。
数据可信度声明
本文整理的是一次真实线上事故的压测与修复过程，所有数据来自我们的生产环境日志和压测报告。涉及的数字：
- 8家门店，每店每天约40个预约时段
- 周末高峰期并发预约峰值：52个请求/秒
- 事故当天超卖单数：14单（涉及3个门店、2个时段）
- 排查用时：4小时
- 修复后超卖率：降到0
第一步：先看预约记录，别一上来就改数据库
很多人看到超卖第一反应是"数据库脏了"，直接去改预约记录。其实应该先统计一下超卖的分布：
-- 查同一个门店同一个时段的预约数量
SELECT store_id, time_slot, COUNT(*) as cnt
FROM reservation
WHERE store_id = 101
AND reserve_date = '2026-09-21'
GROUP BY store_id, time_slot
HAVING cnt > 5; -- 每个时段应该只有5个名额
我们当时查出来的情况：
- 周六下午2点这个时段，3号店应该是5个名额
- 实际约了7个人
- 所有预约都是在1分钟内提交的
这就坐实了：不是数据库脏了，是同一个时段被并发约超了。
第二步：查并发请求日志，看是不是同时打过来的
预约记录没问题，下一步看请求日志——这些预约是不是几乎同时打过来的？
先理清楚一个完整的预约流程：用户选门店→选日期→选时段→填信息→提交预约。看起来很简单，但高峰期问题就出在最后一步——"提交预约"这个动作。
高峰期的时候，很多用户会盯着放号时间抢预约，比如早上10点开放周末预约，9:59:50就有一堆人在刷页面，10:00:00一到，几十上百个请求同时打过来。这就是并发问题的温床。
# 查预约接口的请求时间分布
grep "POST /api/reservation" access.log | awk '{print $4}' | cut -d: -f2-4 | sort | uniq -c
我们当时查出来的情况：
- 1分钟内有12个请求打向同一个时段
- 12个请求几乎同时到达后端（时间差都在100ms以内）
- 后端每个请求都查了一遍库存，发现"还有名额"，就都落库了
这就是经典的"先查后写"并发问题：两个请求同时查库存，都看到"还有1个名额"，然后都写进去了，结果库存变成-1。
第三步：修——加行锁，别让两个请求同时扣名额
修复分两步：
临时止血——给预约扣名额加悲观锁：
@Transactional
public boolean createReservation(Long storeId, String timeSlot, Long userId) {
// 先加行锁，锁住这个时段的记录
TimeSlot slot = timeSlotMapper.selectForUpdate(storeId, timeSlot);
if (slot.getBookedCount() >= slot.getCapacity()) {
throw new RuntimeException("该时段已约满");
}
// 名额还有，加预约
reservationMapper.insert(storeId, timeSlot, userId);
// 更新已约数量
timeSlotMapper.incrementBookedCount(storeId, timeSlot);
return true;
}
根治——容量预估提前算好，别等高峰期再调：
# 提前预估每个时段需要多少名额
def estimate_capacity(store_id, date):
# 历史同期预约量
historical_avg = get_historical_avg(store_id, date)
# 大促/活动系数
activity_factor = get_activity_factor(date)
# 预留20% buffer
capacity = int(historical_avg * activity_factor * 1.2)
return capacity
改完之后，我们压测了100个并发请求约同一个时段（5个名额），最后成功预约的正好是5个，超卖率从2.3%降到了0。
踩坑清单
坑1：用Redis做库存但不做数据库兜底——有人用Redis预扣库存，但Redis和数据库之间没有同步机制，Redis挂了或者数据不一致，数据库里还是会超卖。Redis预扣只是优化性能，真正的一致性必须靠数据库。
坑2：先查库存再扣，中间没加锁——"SELECT查库存→判断够不够→INSERT预约"这三步如果不在一个事务里、不加行锁，并发时就会出问题。两个请求同时查到"还有1个名额"，然后都插入了，就超卖了。
坑3：容量拍脑袋定，不看历史数据——每个时段放5个名额还是10个？拍脑袋定的话，要么放少了约不满，要么放多了超卖。一定要用历史同期数据做预估，再留20%buffer。
坑4：周末高峰期没做排队机制——高峰期同时抢预约的人多，直接打进来容易超卖。应该做排队机制：用户先排队，系统按顺序处理，约满了就提示"前面还有X人"。
坑5：上线前没压测过并发预约——平时一天几十单，并发看不出问题。周末高峰期一秒几十个预约，并发锁的问题全暴露了。上线前一定要压测：100并发约同一个时段，看会不会超卖。
写在最后
门店预约超卖这件事，说复杂也复杂，说简单也就三步：预约记录看分布、并发日志看时间、数据库加行锁。我们这次花了4小时定位，其中2.5小时都在怀疑是数据库脏了，最后才发现是并发请求同时打进来的。后来把这套排查路径固化成runbook，下次类似问题15分钟就能定位到方向。
回头看，这次事故给我们最大的教训是：不要把"库存扣减"当成一个简单的写操作。只要是高并发场景下的库存扣减，就必须考虑并发安全问题——不管是电商库存、还是预约时段、还是优惠券领取，本质上都是同一个问题。悲观锁、乐观锁、Redis预扣，选哪种方案要根据业务场景定，但"并发扣减必须加锁"这个原则不能变。
预约系统治理没有银弹，但有几个红线值得记：并发预约必须加行锁、容量预估必须看历史数据、大促前必须压测。这三件事做到位，客诉里的"约满"能少一大半。
