并发预约竞态条件分析

Concurrent Booking Race Condition — 2026-02-08 — 架构与稳定性

1. 问题本质：TOCTOU 竞态

TOCTOU（Time-of-Check vs Time-of-Use）是并发系统中最经典的竞态条件之一。在预约场景中表现为：

时序图：无锁情况下的竞态

关键点：在 t1 时刻，A 的 INSERT 尚未执行（或未 COMMIT），B 在默认 READ COMMITTED 隔离级别下看不到 A 未提交的数据，因此冲突检查返回"无冲突"。

2. 触发场景

3. 当前防护体系（修复前）

4. 修复方案：Advisory Lock + EXCLUDE 约束

方案 C：pg_advisory_xact_lock（主防线）

-- 在 BEGIN 之后立即执行
SELECT pg_advisory_xact_lock(
  hashtext(employee_id || '::' || scheduled_date)
);
-- 锁在 COMMIT/ROLLBACK 时自动释放

时序图：有 Advisory Lock 的情况

关键优势：pg_advisory_xact_lock 绑定事务生命周期，COMMIT/ROLLBACK 时自动释放，不会死锁（除非应用层有循环依赖）。

方案 A：EXCLUDE USING gist 约束（终极兜底）

-- 需要先安装扩展
CREATE EXTENSION IF NOT EXISTS btree_gist;

-- 在 appointments 表上添加排斥约束
ALTER TABLE appointments ADD CONSTRAINT exclude_employee_time_overlap
  EXCLUDE USING gist (
    employee_id WITH =,
    tsrange(scheduled_datetime, end_datetime) WITH &&
  ) WHERE (status NOT IN ('cancelled', 'no_show', 'void'));

5. 所有预约创建入口（6 个）

6. 业界更大规模并发下的挑战

当并发量从"美甲沙龙级"（几十 QPS）上升到"演唱会抢票级"（几万 QPS）时，会遇到以下问题：

6.1 热点行锁争用（Lock Contention）

当热门技师/资源被大量请求同时争抢时，advisory lock 或行锁会导致大量请求排队等待。表现为：响应时间飙升、连接池耗尽、级联超时。

6.2 数据库连接池耗尽

每个等待锁的请求都占用一个数据库连接。如果锁等待时间长（比如事务内有外部 API 调用），连接池会被占满，后续请求直接失败。

6.3 分布式环境下的一致性

当系统扩展到多个数据库实例（读写分离、分库分表）时，pg_advisory_lock 只在单个 PG 实例内生效，需要引入分布式锁。

6.4 超卖问题（Overselling）

类似电商秒杀的库存超卖。如果可用时段被视为"库存"，高并发下可能多卖。

7. 业界最佳实践

各方案详解

UPDATE slots SET booked = true
WHERE id = $1 AND version = $2
RETURNING id;

const lock = await redis.set(
  `lock:emp:${empId}:${date}`,
  requestId, 'NX', 'EX', 30
);

8. 实施清单