需要本地缓存，因为redis存在网络延迟（1–10ms）、单节点性能瓶颈（读约10万qps）及集群故障时无降级能力，而本地缓存访问延迟仅0.1μs、可分流70%以上请求并提供容灾兜底。
秒杀库存扣减为什么不能只靠数据库事务？
单纯用 SELECT ... FOR UPDATE 加行锁，在高并发下会迅速堆积大量等待事务，导致超时、死锁或连接池耗尽。MySQL 默认隔离级别下，即使只更新一条记录，也可能因间隙锁（gap lock）锁住整个范围，让后续请求排队——这不是性能问题，是架构瓶颈。
- 真实场景中，1000 QPS 的抢购请求，可能只有不到 5% 能真正走到数据库写入层
- 库存字段若放在主业务表（如
Product），每次扣减都触发全表二级索引维护，放大锁竞争 -
UPDATE product SET stock = stock - 1 WHERE id = 123 AND stock > 0看似原子，但 MySQL 仍需先查再判断再改，中间存在“检查-执行”时间窗
用 Redis 原子操作做前置过滤，但要注意 Lua 脚本的边界
把库存计数放到 Redis，用 DECR 或 Lua 脚本保证扣减原子性，是主流做法。但别直接用 decr：它不校验当前值是否 ≥1，可能扣成负数。
推荐用以下 Lua 脚本（通过 redis.eval 调用）：
if redis.call("GET", KEYS[1]) >= ARGV[1] then
return redis.call("DECRBY", KEYS[1], ARGV[1])
else
return -1
end
-
KEYS[1]是库存 key（如"seckill:1001:stock"），ARGV[1]是扣减数量（通常为 1） - 脚本必须在 Redis 单线程内执行完，不存在竞态；返回 -1 表示库存不足，可直接拒绝请求
- 注意：Lua 脚本里不能调用
redis.call("INCR")后再判断，那会破坏原子性
Django 视图里怎么避免把 Redis 和 DB 操作混在同一事务里？
很多人写成“Redis 扣成功 → Django ORM 创建订单 → DB 提交”，结果 Redis 扣了但 DB 写失败，导致超卖。正确做法是：Redis 只管“资格认证”，DB 才管“最终落库”，两者解耦。
- Redis 阶段只做
DECR或 Lua 校验，成功即发 MQ 或进队列，视图立即返回“已排队” - 用 Celery 或 Django-Q 处理异步订单创建，失败时回滚 Redis（用
INCRBY补回） - 不要在视图里用
transaction.atomic包裹 Redis 操作——它对 Redis 无效，反而拖慢响应 - DB 订单表建议加唯一索引（如
user_id, item_id, seckill_event_id），防止重复下单
为什么漏斗分层里 Redis 之后还要加本地缓存？
当单机 QPS 过万，Redis 网络往返和序列化开销会成为瓶颈。这时可以在 Django 应用进程内加一层 LRU 缓存，比如用 functools.lru_cache 或 django.core.cache.caches['locmem'] 缓存“该商品是否已售罄”这种确定性状态。
- 缓存 key 设为
"seckill:{item_id}:sold_out"，TTL 设短（如 1 秒），避免状态滞后 - 仅缓存“已售罄”信号，不缓存具体库存数——因为库存数实时变化，缓存它反而引入不一致
- 本地缓存失效后才打 Redis，能过滤掉约 60%–80% 的无效请求，大幅降低 Redis 压力
真正难的不是写对一行 DECR，而是让 Redis、DB、缓存、队列四层之间不互相绑架。每层只承担自己能稳住的部分，出问题时有明确回滚点，而不是堆参数硬扛。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
