必须将批量写入key与业务key隔离在不同淘汰域，否则allkeys-lru等策略会无差别淘汰高频访问的session key；所有业务key须设合理TTL，批量key TTL应更短，并统一用allkeys-lfu策略配合bulk:前缀实现可预测淘汰。
必须让批量写入的 key 和业务 key 分属不同淘汰域，否则淘汰策略会无差别“杀熟”。 Redis 的淘汰机制不认业务优先级，只看内存压力和策略规则。你用 MSET 一口气塞进 10 万个缓存，哪怕它们都带 EXPIRE，只要内存触顶，allkeys-lru 就可能顺手把正在被高频访问的用户 session key 删掉。
为什么 allkeys-lru 会误伤重要业务 Key
淘汰策略只看“最近是否被访问过”，不区分 key 是临时报表数据还是登录态。常见误配是：业务 key（如 user:session:abc123）没设 TTL，而批量导入的 key（如 report:20261020:xxx）设置了 5 分钟 TTL。此时若用 volatile-lru，它只淘汰带过期时间的 key —— 看似安全，但一旦这批 report key 过期前就被大量读取，它们在 LRU 链表里就排到了前面，真正该保留的 session key 反而成了“冷数据”被踢出。
- 所有业务 key 必须显式设置合理 TTL（比如 session 设 30 分钟，token 设 2 小时），不能依赖“永不过期”来保命
- 批量导入 key 的 TTL 要明显短于业务 key（例如 report 设 60 秒，而非 5 分钟），确保它们在内存紧张时优先被淘汰
- 避免混用
volatile-*和allkeys-*策略：如果业务 key 全部带 TTL，用allkeys-lru更可控；如果部分 key 永不过期（如配置类），则必须用allkeys-lfu或allkeys-random，否则volatile-*完全失效
用命名空间 + 淘汰策略隔离批量 key
靠 key 前缀本身不能阻止淘汰，但配合策略能大幅降低误伤概率。关键不是“分类”，而是“让淘汰逻辑可预测”。比如把批量导入 key 统一加 bulk: 前缀，并在写入前确认：
- Redis 实例已配置
maxmemory-policy allkeys-lfu（LFU 更倾向保留高频访问 key，比 LRU 对业务更友好） - 批量脚本中所有
bulk:key 的 TTL 设为固定短值（如 30 秒），且写入后不做任何读取，确保它们在 LFU 计数器里始终为 0 - 业务 key 使用
user:、order:等前缀，且访问频次远高于 bulk key，这样 LFU 自然会保护它们
批量写入前必须检查的三项配置
跳过这三步，脚本跑得越快，线上抖动越猛：
- 执行
redis-cli CONFIG GET maxmemory，确认非 0；若为 0，立刻设上限（如2gb），否则批量写入直接触发 OOM Killer 杀进程 - 执行
redis-cli CONFIG GET maxmemory-policy，禁止使用noeviction（写入失败）或volatile-ttl（对无 TTL 的业务 key 完全无效） - 用
redis-cli --scan --pattern 'bulk:*' | head -n 10 | xargs -I{} redis-cli TTL {}抽样验证批量 key 是否真有 TTL —— 很多框架（如 Spring Data Redis 的boundHashOps.putAll()）默认不带过期，得手动补
真正难的不是写脚本，而是让批量行为和业务生命周期对齐：bulk key 要像一次性的便签纸，写完即焚；业务 key 要像带心跳的活体，持续被访问才能存活。淘汰策略不会读你的注释，它只认内存、访问频次和 TTL 这三样东西。
