极端并发下的库存准确性是电商最难的问题之一。超卖造成糟糕的客户体验和法律问题，少卖意味着收入损失。这道题考察你将缓存、原子操作和分布式系统知识结合成实际方案的能力。
解释为什么简单的数据库行锁在此规模下不可行：锁竞争导致吞吐量崩塌。
描述Redis + Lua原子扣减方案处理热点路径。
覆盖异步对账流程：Redis扣减→消息队列→数据库确认。
处理边界情况：Redis和数据库不一致怎么办？退款如何处理？
我会实现三层库存系统。第一层——预过滤：秒杀开始前将总库存加载到Redis。每个请求用Lua脚本原子地检查库存>0并递减，亚毫秒延迟处理热点路径，超限请求立即拒绝。Lua脚本保证原子性，无需分布式锁。第二层——异步下单：Redis扣减成功后发消息到RocketMQ，订单服务消费者在本地事务中创建订单并扣减数据库库存。如果数据库扣减失败（如数据不一致），补偿消息归还Redis库存。第三层——对账：定时任务每30秒对比Redis库存计数和数据库已确认订单数，差异触发告警和自动修正。防超卖方面，Redis库存设为实际库存的99%作为安全缓冲，剩余1%仅通过数据库路径供后来者使用。退款反向操作：先数据库加回，再通过消息队列递增Redis。
Redis Lua脚本是关键亮点——明确提到并解释为什么它优于分布式锁。
一定要提对账机制——面试官要看你关注正常路径之外的数据一致性。
提到"超卖vs少卖"的权衡：轻微少卖在商业上远好于任何超卖。
WATCH/MULTI使用乐观锁，高竞争下大量重试。Lua脚本在Redis服务端原子执行，无需多次往返，在并发访问下提供原子性和更高吞吐。
用Redis Sentinel或Cluster做高可用。主节点故障后副本秒级提升。短暂切换窗口内请求可以排队或快速失败提示重试。恢复后从数据库对账Redis状态。