不能只靠 volatile-lru 保护关键数据，因其仅按访问时间淘汰而无法识别业务重要性；应将关键数据设为永不过期并用前缀隔离，搭配 allkeys-lru 或 noeviction 策略及监控兜底。
为什么不能只靠 volatile-lru 保护关键数据
在混合存储场景（比如缓存 + 会话 + 临时计数共存）中，如果所有 key 都设置了 TTL，又统一用 volatile-lru，Redis 会一视同仁地淘汰“最近最少访问”的键——哪怕它是用户登录态的 session:abc123，只要近期没被读过，就可能被踢掉。这不是策略错了，而是它根本没能力识别“这个 key 多重要”。volatile-lru 只看访问时间，不看业务语义。
用前缀隔离 + noeviction 或 allkeys-lru 组合更可控
真正防淘汰，得让 Redis “知道哪些不该动”。最直接的办法是：把关键数据（如登录态、订单锁、核心配置）全设为永不过期（不带 TTL），再搭配合适的淘汰策略。
- 给关键数据统一加前缀，比如
critical:session:、critical:config:，写入时明确不设EX或PX - 非关键数据（如热点商品缓存、临时统计）用带 TTL 的 key，例如
cache:product:1001、tmp:counter:20260904 - 配置
maxmemory-policy为allkeys-lru或allkeys-lfu：这样 Redis 会在**所有 key 中**淘汰，但因为关键 key 没 TTL，它们天然不会被volatile-*类策略选中；而allkeys-*策略虽然能淘汰它们，只要你没手动删或覆盖，它们就始终存活 - 更保守的做法：对关键数据所在实例单独启用
noeviction，配合监控告警——一旦内存触顶，宁可写失败也不淘汰，由上层兜底（比如降级到 DB 查询）
前缀本身不防淘汰，但它是人工治理的锚点
Redis 不解析 key 前缀，critical: 这个字符串对淘汰逻辑完全透明。它的价值在于：让你能用 KEYS critical:* 或 SCAN 快速定位关键数据；在脚本清理、备份、迁移、监控维度聚合时，前缀就是唯一可依赖的业务标识。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 运维脚本定期检查
critical:类 key 的 TTL：如果意外被设了过期时间，立刻用PERSIST去除 - 监控大盘按前缀分组统计内存占比，发现
critical:区域突增，说明有异常写入（比如误把大对象塞进 session 前缀） - 切片集群中，前缀还能辅助 slot 分布设计——比如把所有
critical:key 显式HASH到固定 slot，避免跨节点操作
容易忽略的陷阱：内存碎片和元数据开销
前缀加得太多、太长，反而会放大问题。每个 key 的元数据（包括 key 字符串本身）都要占内存，critical:session:uuid4... 比 s:u... 多占十几字节。百万级 key 下，光前缀就吃掉几十 MB。
- 前缀长度控制在 8–12 字符内，比如用
cr:替代critical:，用sess:替代session: - 避免嵌套前缀，如
critical:cache:product:—— 这既增加长度，又模糊了数据类型边界 - 警惕
DEL/FLUSHDB误操作：前缀只是命名习惯，不是权限隔离，一个KEYS critical:* | xargs redis-cli DEL就全清空了
前缀不是银弹，它解决不了策略误配或 maxmemory 设得太小的问题。真正的防线是：关键数据不设 TTL + 策略选 allkeys-* 或 noeviction + 监控补位。前缀只是让这套逻辑可维护、可追溯、可审计。
