Redis 本身不提供「多级缓存淘汰」的内置机制，所谓「多级缓存淘汰」是业务层设计概念，必须靠 Lua 脚本在 Redis 内部协调 ngx.shared（Nginx 共享字典）、redis 和 mysql 三级数据状态，并手动控制淘汰时机与策略。
直接说结论：Redis 本身不提供「多级缓存淘汰」的内置机制，所谓「多级缓存淘汰」是业务层设计概念，必须靠 Lua 脚本在 Redis 内部协调 ngx.shared（Nginx 共享字典）、redis 和 mysql 三级数据状态，并手动控制淘汰时机与策略。关键不在脚本多复杂，而在淘汰触发点是否合理、数据一致性是否可保。
为什么不能只靠 Redis 的 maxmemory 策略？
Redis 的 volatile-lru、allkeys-lfu 等淘汰策略只作用于 Redis 自身内存，对 Nginx 的 lua_shared_dict 或后端 MySQL 完全无感知。比如你用 allkeys-lfu 淘汰了 Redis 中某个热点 key，但 Nginx 缓存里还留着旧副本，下次请求直接返回脏数据——这不是淘汰，是数据错乱。
常见错误现象：
- 用户修改数据后，前端仍看到旧内容，刷新几次才变
- Redis 因内存满被自动淘汰，但 Nginx 缓存未同步失效，导致「缓存永远不更新」
-
ngx.shared设置了 10 分钟 TTL，Redis 却设了 5 分钟，结果 Redis 先过期，Nginx 还在用无效缓存
eval 脚本里怎么统一控制三级缓存生命周期？
核心原则：所有写操作（如更新、删除）必须走 Lua 脚本，由它主动驱逐下游缓存，而不是等自动过期。读路径可以分层查，但写路径必须「一写全清」或「一写全更」。
实操建议：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 写 MySQL 前，先用
redis.call("del", "content_"..id)清 Redis，再用ngx.shared.dis_cache:delete("content_cache_"..id)（注意：这个调用需在 Nginx Lua 层完成，不能放进 Redis 脚本） - 如果要「更新而非删除」，在 Lua 脚本里用
redis.call("setex", "content_"..id, 300, new_json)，同时通过 Nginx 的cache_ngx:set(..., 300)同步设置相同 TTL - 避免在 Lua 脚本里调用 MySQL —— Redis 不支持直连 MySQL，所有 DB 操作必须在 Nginx Lua 层完成；Lua 脚本只负责 Redis + 通知逻辑
- 不要用
expire命令单独设 TTL，一律用setex/setnx带时间参数，保证原子性
哪些场景必须用 evalsha 而不是 eval？
当淘汰逻辑复用度高（比如「清除某类 key 的全部缓存」），且并发量大时，evalsha 能显著降低网络开销和 Redis CPU 压力。每次完整脚本传输几百字节，高频写场景下容易成为瓶颈。
示例（清除某 category 下所有 content 缓存）：
local pattern = "content_" .. ARGV[1] .. "_*"
local keys = redis.call("keys", pattern)
for i, key in ipairs(keys) do
redis.call("del", key)
end
return #keys
使用方式：
- 首次用
script load加载，得到 SHA1 值（如"a1b2c3..."） - 后续全部用
evalsha "a1b2c3..." 0 123，其中123是 category_id - 注意：如果 Redis 重启，SHA1 会失效，客户端需 fallback 到
eval并重新 load
真正难的不是写几行 Lua，而是决定「什么时候该淘汰」——比如是删完 MySQL 就立刻清缓存，还是等 MQ 消息确认后再清；是清单个 key，还是按 pattern 批量清；Nginx 字典要不要也参与 LRU 管理（靠定时任务扫描？还是靠写操作触发？）。这些决策点，比语法细节更容易出线上事故。
