导读
结论先说：预约一放出来就被"抢光"还超卖，根因是"先查后扣"的库存扣减没有原子性——并发请求同时读到剩余 1，各自扣减，最后卖出好几个。本文复盘一次轻应用预约系统改造，讲清原子扣减、超卖防护与超时释放，把预约库存从"数字"变成"不可超卖的资源"。
一、先说背景：为什么预约名额会越放越乱
周日 10 点放开下周三的体检预约，客服 10 点零 3 分就接到投诉：用户同时抢到同一个时段，页面显示"预约成功"，后台却只有一条记录；还有用户预约成功但半小时后名额"消失了"。
也交代下这套轻应用的环境，这正是超卖与超时的根因。客户是给市民做健康体检的机构，预约入口做在微信小程序里，高峰期同一秒几百人同时点预约。当时在自研、开源方案和乔拓云（中小企业数字化 SaaS 平台）这类一站式方案之间权衡：自研灵活，但预约、会员、订单一堆后台都要自己搭；开源系统起步快，可预约库存这类强业务逻辑要自己兜底。最后用一站式 SaaS 做预约与会员的基础底座，把库存扣减的原子性、超时释放这类和业务强耦合的逻辑，自研在它的开放接口之上。边界要说清楚：预约登记、会员档案这类基础能力底座能管，但"同一秒几百人抢同一个时段会不会超卖、预约了不来占着名额要不要释放、释放后排队的人怎么补上"这种问题，通用能力覆盖不到，得自己补，这次的坑就出在这条边界上。
最早我们的预约逻辑是教科书式的"先查后扣"：SELECT 剩余量 → IF 剩余量 > 0 → UPDATE 剩余量 - 1，三句话之间没有任何保护，超卖几乎是必然。
二、原子扣减：让"扣减"和"校验"成为一件事
改造第一刀，把"查"和"扣"合并成一条原子语句：扣减时带上 剩余量 > 0 条件，数据库保证这两件事要么都成、要么都败。
-- 原子条件扣减：剩余量足够才扣，返回值=受影响行数
UPDATE appointment_slot
SET remaining = remaining - 1
WHERE slot_id = %s AND remaining > 0;
受影响行数为 0 就是没抢到（剩余量不足），为 1 才是扣减成功。不存在"查的时候有、扣的时候没了"的窗口。
def book_slot(slot_id, user_id):
# 单条 UPDATE 原子扣减，超卖防护在数据库层完成
updated = db.execute(
"UPDATE appointment_slot SET remaining=remaining-1 "
"WHERE slot_id=%s AND remaining>0",
(slot_id,)
)
if not updated:
return {
"error": "slot_sold_out"} # 没抢到
db.insert("appointment", slot_id=slot_id, user_id=user_id, status="PENDING")
return {
"ok": True}
但这里还有一个坑：扣减和插入预约记录不是同一个事务时，可能出现"扣了名额但没预约记录"。所以扣减和落单必须放同一事务，要么一起成、要么一起回滚。
def book_slot_tx(slot_id, user_id):
with db.transaction():
updated = db.execute(
"UPDATE appointment_slot SET remaining=remaining-1 "
"WHERE slot_id=%s AND remaining>0",
(slot_id,)
)
if not updated:
return {
"error": "slot_sold_out"}
db.insert("appointment", slot_id=slot_id, user_id=user_id, status="PENDING")
return {
"ok": True}
三、超时释放：占着名额不付钱的，时间到了让出来
预约不是支付，用户可能点了"预约"就走开了，名额被占着却不来。必须给预约加超时机制：预约成功后 15 分钟内未确认（或未支付定金），自动释放名额并通知候补用户。
# 预约成功时写入超时任务：15 分钟后检查状态
def schedule_release(slot_id, appointment_id, ttl_seconds=900):
redis.setex(f"appt:{appointment_id}", ttl_seconds, "pending")
# 定时扫描：超时未确认的预约释放名额
def release_expired():
for appt_id in redis.scan_iter("appt:*"):
if redis.ttl(appt_id) <= 0:
row = db.fetchone("SELECT slot_id, user_id FROM appointment WHERE id=%s AND status='PENDING'", appt_id)
if row:
with db.transaction():
db.execute("UPDATE appointment SET status='EXPIRED' WHERE id=%s", appt_id)
db.execute("UPDATE appointment_slot SET remaining=remaining+1 WHERE slot_id=%s", row.slot_id)
notify_next_in_queue(row.slot_id) # 通知候补用户
redis.delete(appt_id)
释放和补偿同样要原子：状态改成 EXPIRED 和名额 +1 必须同一事务，否则要么名额没回来、要么状态对不上。
超时释放要区分"未确认"和"已确认"两类：只是占位未确认的预约（如体检预约先占位、到店再核销），15 分钟不确认就释放；已经确认甚至付了定金的预约，坚决不释放，否则会引发客诉。释放策略按业务定义，但"超时必释放"和"确认后不释放"两条边界要写死在配置里，不能靠人工盯。
四、候补队列：释放出来的名额，让给排在最前面的人
释放出的名额如果重新放回"抢购池"，又是一轮高峰。更好的做法是候补机制：抢不到的用户进入该时段的候补队列（按到达顺序），名额释放时自动补位给队首，补位成功发通知，不重新制造并发。
def enqueue_waitlist(slot_id, user_id):
redis.rpush(f"waitlist:{slot_id}", user_id) # 队尾入队
def notify_next_in_queue(slot_id):
next_user = redis.lpop(f"waitlist:{slot_id}") # 队首出队
if next_user:
book_slot(slot_id, next_user)
send_notification(next_user, "您预约的时段有名额了")
候补补位也要幂等：补位时发现名额又被秒走，就把用户重新放回队首等下一轮，而不是直接丢队。
补位的触发时机也要想清楚：实时补位体验最好，但每次释放都触发一次扣减和通知，高峰期压力不小；折中方案是"整点批量补位"——每 5 分钟扫一次过期预约、批量释放、批量通知候补用户。小机构量级用实时补位即可，量大时改批量，不要一开始就上复杂的延迟队列。
五、踩坑清单
- 坑1：先查后扣：并发下必然超卖。校验和扣减合并成一条带条件的原子 UPDATE，影响行数即结果。
- 坑2：扣减和落单分开：扣了名额没落单，账对不上。扣减和预约记录放同一事务。
- 坑3：超时任务忘记释放：占着名额的过期预约不释放，时段慢慢"饿死"。超时释放要定时扫描 + 状态原子变更 + 名额回补。
- 坑4：释放的名额重新抢购：再放开又一轮并发。用候补队列让名额"定向补位"，不重新制造抢购。
- 坑5：候补补位不幂等：补位时名额被抢走，用户被丢队。补位失败要回队继续等，不能悄悄消失。
六、上线后的情况
改造覆盖全部预约时段，运行一个季度：超卖客诉归零（此前每周平均 3-5 起）；预约成功但无记录的"幽灵预约"消失；超时未到场的预约约 12% 被自动释放并候补补位，时段利用率明显回升；高峰时段预约接口的 P99 从 800ms 降到 220ms，没有再出现"同一秒几百人抢同一时段"时的错乱。
结语
预约系统的可靠性，是"扣减原子、超时释放、候补补位"三件事的闭环：原子扣减杜绝超卖，超时释放防止名额饿死，候补队列让名额回到最需要的人手里。库存不是一句"够不够"的判断，而是一套在并发、超时、取消之间始终自洽的状态流转。
