Redis不支持按key前缀配置独立淘汰策略，所有maxmemory-policy均为实例级全局生效；必须通过实例分离、禁用TTL、ACL限制等外部手段实现前缀保护，而非依赖内置机制。
Redis 本身不支持按 key 前缀配置独立淘汰策略，所有 maxmemory-policy 都是实例级全局生效的。所谓“保护特定前缀 key”，必须靠外部设计规避淘汰，而非依赖 Redis 内置机制。
为什么不能直接配置 prefix-level 淘汰策略
Redis 的淘汰逻辑在内存满时统一扫描整个键空间（或 volatile 键子集），不识别 key 名结构，也不支持正则、通配符或命名空间分组。即使你用 user:123、cache:abc 这类前缀组织数据，allkeys-lru 仍可能把 user:999 和 cache:xyz 一视同仁地淘汰。
常见误解是以为 CONFIG SET maxmemory-policy volatile-lru 能“保护无过期时间的前缀 key”——但实际只是把淘汰范围限定在带 EXPIRE 的 key 上，和前缀无关；若你给所有 cache: key 都设了 TTL，而 user: key 全不设，那确实能间接“保 user”，但这属于策略误用，且风险极高：一旦漏设 TTL，该 key 就完全暴露在淘汰范围内。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真正可行的前缀保护方案：分离 + 约束
想让 user: 类 key 不被淘汰，核心思路是物理隔离 + 行为约束：
- 用独立 Redis 实例或数据库（
SELECT 1）专存需保护的 key，只对缓存库启用allkeys-lru；生产环境更推荐实例分离，避免 DB 切换开销和误操作 - 若只能共用实例，强制所有
user:key 不设 TTL，并配置maxmemory-policy volatile-lru——此时淘汰只发生在带过期时间的 key 中，user:key 因无EXPIRE标记而免疫。但必须配套监控：redis-cli --scan --pattern "user:*" | xargs -n 1 redis-cli ttl定期检查是否混入了 TTL - 在应用层拦截写入：对
user:命名空间的 key，禁止调用SETEX/SET ... EX，统一走SET；同时禁用EXPIRE命令对该前缀的操作（可用 Redis ACL 限制）
容易被忽略的陷阱：TTL 泄露与 LFU 干扰
即使用了 volatile-lru，以下情况仍会导致“保护失效”：
- 你给
user:1001错误执行了EXPIRE user:1001 3600，它立刻进入 volatile 键集合，下次内存紧张时就可能被 LRU 淘汰 -
allkeys-lfu策略下，访问频次低的user:key（如冷用户资料）比高频cache:key 更容易被淘汰，此时前缀毫无意义 - 使用
SCAN扫描 key 时未加MATCH user:*，导致批量操作误伤；Redis 的SCAN本身不保证原子性，高并发下可能漏 key 或重复扫
最稳妥的做法永远是：关键数据不进缓存库，或者用单独实例承载。任何基于命名空间的“软保护”，本质都是靠人工守约和监控兜底，不是机制保障。
