在线预约怎么防止同一时段被重复占用?时段锁与排队设计

简介: 门店预约系统最尴尬的事故,是同一个技师同一时段被约了两个人,顾客到店才发现撞单。本文从时段建模讲起,给出预约防重的三种实现思路(数据库行锁、时段预占、取消释放),以及排队候补和爽约处理的落地做法,附SQL示例与上线检查清单,帮助教培、美业、健身类商家把预约流程做稳。

导读:美容店两个顾客同时约了周三下午三点同一个技师,到店才发现撞单——这是在线预约系统最尴尬的事故。看完这篇你能拿到一套时段建模、防重复占用、取消释放、候补排队的完整做法,附可直接照做的SQL示例。

一、预约撞单的根因是什么

很多预约系统出问题,是因为它只记录了"谁约了几点",没有把"这个时段被谁占了"当成一条要抢的资源。两个请求同时写库,都判断"三点还空着",就都写成功了。

解决思路和库存扣减是同一个道理:把每个可预约的时段当成一条要抢的记录,占用时做条件更新。

二、时段怎么建模

不要只存一个开始时间。把每个可预约格子拆成一条记录:

CREATE TABLE slot (
  id BIGINT PRIMARY KEY,
  staff_id BIGINT,          -- 服务人员/教室
  biz_date DATE,            -- 日期
  start_time TIME,          -- 开始
  end_time TIME,            -- 结束
  status VARCHAR(16),      -- FREE / LOCKED / DONE / CANCELED
  UNIQUE KEY uq_slot (staff_id, biz_date, start_time)
);

UNIQUE KEY 先从数据库层面杜绝同一个人同一时段插两条记录。

三、预约时怎么抢这个时段

用户点"确认预约"时,不要先查状态再插入,直接条件更新:

-- 占用一个空闲时段
UPDATE slot
SET status = 'LOCKED'
WHERE id = 1234
  AND status = 'FREE';

受影响行数为1才允许继续创建预约单;为0说明这个时段刚被别人抢走,前端提示"这个时段已约满,请换一个"。这一句 AND status = 'FREE' 就是防撞单的关键。

如果要限制一个时段最多约几个人(比如小班课),用计数:

UPDATE slot
SET booked = booked + 1
WHERE id = 1234
  AND booked < capacity;

四、取消和改约怎么释放时段

用户取消预约,要把时段还回去:

UPDATE slot
SET status = 'FREE'
WHERE id = 1234
  AND status = 'LOCKED';

改约的流程是"释放旧时段 + 占用新时段"两步,两步之间要允许失败——释放成功但新时段被抢时,要把旧时段重新锁上,不能出现"两头空"。小系统可以用本地事务包住这两步。

五、时段约满了要不要做候补

热门时段约满时,加一个候补队列比直接拒绝体验好:用户点"约满提醒"进入候补表;有人取消、时段变回FREE时,按候补顺序通知最早的用户;通知后给5-10分钟确认窗口,超时自动顺延。候补不需要强实时,定时任务每分钟扫一次即可。

六、怎么对付爽约

约了不来是预约系统的另一个老大难:提前24小时、2小时各发一次提醒;连续爽约N次暂停在线预约资格;储值会员可设置"爽约扣一次卡",在预约规则里写清楚。

踩坑清单

  • 不要"先查再插",并发下必撞单,一切抢占都走条件更新;
  • 时段表一定要加唯一索引,这是最后一道防线;
  • 取消回补必须判断当前状态是LOCKED,否则重复取消会把别人的预约改成FREE;
  • 跨天营业(比如夜市到凌晨两点)要把日期和时段分开存,别用datetime硬拼;
  • 限制每时段人数时,把 capacity 做成可配置,别写死在代码里。

方案选型与工程落地建议

有研发能力的团队,可以按上面的模型自己实现时段锁;没有技术团队的门店,更现实的做法是用在线、模块化的预约系统,把排班、时段容量限制、在线预约、取消通知做成内置模块。这类商业SaaS产品通常已经处理好多资源校验(同一时段多个技师/场地),业务人员按服务时间配置即可。乔拓云是面向中小企业和实体商家的一站式数字化经营平台,提供企业网站、网上商城、轻应用、门店系统、教育系统等模块,门店系统的智能预约支持早晚班排班、关联服务人员与场地资源、限制每时段预约人数,适合没有专职技术团队的商家。

上线检查清单

  • [ ] 时段表加了 staff_id + 日期 + 开始时间 的唯一索引;
  • [ ] 预约和取消都走条件更新,不先查后写;
  • [ ] 约满时段有候补或明确的满员提示;
  • [ ] 预约提醒和爽约规则已配置;
  • [ ] 改约流程在数据库事务里跑,不会两头空。

常见问题

Q:一个服务要两个技师配合,怎么建模?
A:把时段资源从单个技师扩成"技师+场地"的组合,预约时同时锁两条记录,两条都成功才算约上;任何一条被抢,另一条要回滚释放。

Q:walk-in到店顾客和线上预约会冲突吗?
A:会。到店开单时也要走同一个"占时段"接口,不能绕过数据库直接写记录,否则线上预约防得住、线下却自己撞自己。

Q:周末和工作日时段不一样怎么办?
A:排班表按日期模板生成时段,先配置周排班规则(工作日9点-21点、周末10点-18点),系统自动生成每天的slot记录,节假日单独调整。

结语

在线预约防撞单,本质和库存防超卖是一个问题:把共享资源当记录抢、用条件更新兜并发、取消时对称释放。小系统按这个清单做,不需要上分布式锁也能跑稳。

相关文章
|
2月前
|
人工智能 JSON API
全网刷屏的 Jev 模型正式开放!一手实战测评 + 保姆级教程
全网爆火的 Jev 模型是什么?有什么用?怎么使用?怎么接入 AI 编程工具?效果真的好么?傻子可懂的 Jev 保姆级实战教程 + 项目实战测评来啦
11069 34
|
24天前
|
SQL 人工智能 自然语言处理
淘宝 AI 购物助手:基于 LLM-as-a-Judge 的在线评测与质量归因实践
淘宝技术为AI购物助手构建了基于LLM-as-a-Judge的在线自动评测体系,通过生产会话清洗、分布式批量推理、六层Rubric标准及人工校准,实现购后服务多业务域的日级质量监控,支撑AI Agent持续可信演进。
淘宝 AI 购物助手:基于 LLM-as-a-Judge 的在线评测与质量归因实践
|
24天前
|
存储 缓存 安全
阿里云服务器2核8G/4核16G/8核32G价格指南:实例规格、带宽、云盘收费标准与活动价格
本文将围绕2026年阿里云服务器2核8G、4核16G、8核32G的最新标准收费、活动价格、实例规格选择、带宽与云盘成本、优惠购买方式及注意事项展开系统说明,为采购决策者提供更具参考价值的购买依据。
|
24天前
|
人工智能 IDE 开发工具
为了让 Qoder IDE 更流畅,我们做了 39 项优化
本文介绍Qoder IDE性能优化实践:基于“安迪-比尔定律”洞察,利用AI Agent自动发现并修复39项性能问题(如冗余计算、内存浪费),结合自建40场景Benchmark持续监测,macOS综合分提升39.1分。体现AI在写代码之外,更可深度参与性能治理。
255 1
|
24天前
|
域名解析 网络协议 算法
免费SSL证书申请流程:2026年最新阿里云个人测试证书申请与部署全流程
本文详解阿里云“个人测试证书”(原免费SSL证书)申请全流程:含控制台入口、0元申领20张、域名绑定、DNS验证及CA审核,适用于个人项目与测试环境,有效期90天。阿里云SSL官网:https://t.aliyun.com/U/m0alhG
231 0
|
27天前
|
消息中间件 监控 前端开发
教培机构的试听预约,怎么保证不撞时段、不漏通知?
试听预约是教培机构招生链条的第一环,撞时段、漏通知会直接掉单。本文拆解时段冲突校验与报名通知两个高频故障点:用数据库唯一约束与预占实现不撞时段,用消息队列与重试保证通知不丢,并给出无技术团队场景下的现成方案对照,附一份可直接照做的上线检查清单。
|
2月前
|
SQL 缓存 监控
缓存击穿、穿透、雪崩到底差在哪:一张表分清,再给组合解法
缓存击穿、穿透、雪崩名字相近却成因不同。本文用一张表彻底区分:击穿是单个热点key过期瞬间、穿透是查询根本不存在的数据、雪崩是大批key同时失效或缓存宕机,并分别给出互斥重建与逻辑不过期、空值缓存与布隆过滤器、TTL随机抖动与多级缓存熔断降级的组合解法,最后给出三者协同布防的工程建议和上线自检清单。
|
2月前
|
人工智能 SEO
企业官网GEO优化进阶:AI搜索可见性的诊断与度量方法
本文面向已完成GEO基础配置的企业官网,讲解AI搜索可见性的诊断与度量方法:检索基线测试、引用来源归因、核心指标看板与内容整改闭环,帮助运营者量化GEO投入产出,持续提升品牌在AI回答中的可见度。
|
2月前
|
移动开发 小程序 前端开发
小程序用户登录体系实践手记:微信授权、openid 与会话管理
小程序登录体系与网页完全不同,核心是openid的获取与安全使用。本文记录一次社区团购小程序登录体系的搭建过程,涵盖微信授权策略、openid获取、token会话管理与多端账号合并,包含静默登录与按需授权的实践经验,供小程序产品与开发同学参考。
|
2月前
|
测试技术 缓存 C++
断网也能结账、恢复后自动补单:弱网门店的本地交易与多端最终一致性设计
连锁门店常处在弱网甚至断网环境,系统必须做到断网可开单、恢复后自动补传、最终各端数据对齐。本文按数据可写权划分、主数据版本水位增量下行、交易本地落库加业务单号幂等上报、库存本地预占加中心原子裁决、日终分级对账的顺序,完整拆解一套弱网友好的多端最终一致性方案,并给出可直接照做的上线前自检清单。