之前参与过一个旅游预订系统项目，在大促期间遇到了订单超卖问题，请描述当时的技术方案和后续优化措施。

1) 【一句话结论】当时通过“分布式锁+库存预占”方案解决大促超卖问题，后续优化升级为多级缓存+智能锁，提升并发性能并降低锁竞争。

2) 【原理/概念讲解】超卖本质是并发场景下库存未同步导致重复扣减。技术方案核心是“先锁定库存再扣减”，比如分布式锁保证同一时间只有一个请求处理库存，或预占库存（临时表记录预占信息，大促后统一结算）。分布式锁需注意过期时间（避免死锁）、重入问题（如Redis的SETNX+EXPIRE）；缓存一致性需保证写时同步（数据库+缓存），读时优先从缓存获取（减少数据库压力）。

3) 【对比与适用场景】

方案	定义	特性	适用场景	注意点
悲观锁（分布式锁）	通过锁机制保证互斥访问库存	互斥性强，能直接防止超卖	高并发、库存稀缺场景（如大促）	需处理锁过期、死锁问题
乐观锁（版本号）	通过版本号校验更新	读多写少，冲突时重试	库存更新频率低、读多场景	冲突率高时性能差

4) 【示例】（伪代码）
用户下单请求：

• 获取Redis分布式锁（key="product_1001_user_123"，过期时间=订单处理时长+超时时间）
• 锁获取失败 → 返回“超卖”
• 检查库存（从Redis缓存，若缓存失效则查询数据库）
• 库存不足 → 释放锁 → 返回“库存不足”
• 扣减库存（更新数据库和Redis缓存）
• 释放锁 → 创建订单

5) 【面试口播版答案】当时遇到大促超卖，核心方案是“先锁定库存再扣减”。具体来说，我们用了Redis分布式锁，每个订单请求先尝试获取锁，锁成功后检查库存，库存够就扣减并释放锁，不够就返回错误。后续优化是升级锁为带超时重试的分布式锁，并引入多级缓存（Redis+数据库），减少锁竞争，同时优化库存校验逻辑，比如增加库存预占队列，避免瞬间高并发导致超卖。

6) 【追问清单】

• 1. 如果分布式锁出现死锁怎么办？回答要点：设置锁过期时间（避免死锁），或采用红锁（多节点同时尝试获取锁，第一个成功）。
• 2. 库存数据源是数据库还是缓存？回答要点：当时用数据库作为主库，缓存作为读写分离的缓存层，保证一致性。
• 3. 大促后如何处理预占的库存？回答要点：大促结束后批量更新库存，或根据预占订单生成实际订单。
• 4. 如果系统是微服务架构，如何保证跨服务库存一致性？回答要点：使用分布式事务（Saga模式）或事件驱动（库存更新后发布事件，订单服务订阅）。

7) 【常见坑/雷区】

• 1. 锁过期时间设置不当（过短导致超卖，过长导致死锁）。
• 2. 只用本地锁（如数据库行锁）导致分布式环境下超卖。
• 3. 忽略缓存雪崩，大促时缓存失效引发数据库压力过大。
• 4. 乐观锁在超卖场景下不适用（冲突率高）。
• 5. 预占库存表未及时清理，导致库存数据不一致。