如何保障Redis重要配置信息不被自动淘汰_使用独立实例或noeviction策略

noeviction策略下Redis内存达maxmemory时强制拒绝所有写入，返回OOM错误，确保配置类key不被淘汰；但需配合独立实例、合理maxmemory设置及应用层降级处理。

重要配置信息不会被自动淘汰——前提是它根本不在淘汰范围里，或者你压根没给 Redis 淘汰的机会。

noeviction 策略下写入失败就是明确信号

当配置 maxmemory-policy noeviction 时，Redis 不会主动删任何 key。但一旦内存触达 maxmemory 上限，所有写命令（SET、HSET、LPUSH 等）都会直接报错：(error) OOM command not allowed when used memory > 'maxmemory'。

这不是“数据被悄悄淘汰了”，而是“你连写都写不进去”。所以：

• 配置类 key（比如 config:redis:timeout、settings:feature:flag）只要成功写入，就永远在内存里
• 但如果你没做容量预估，或没监控 used_memory，业务可能突然卡在写配置这一步
• CONFIG SET 命令本身不受 noeviction 影响，但修改 maxmemory 后新写入仍会触发 OOM

独立实例比策略更可靠，但代价是资源

用一个只存配置的 Redis 实例（比如 redis-config），配合 noeviction + 合理的 maxmemory（例如 16MB），是最稳妥的做法。

原因很实际：

• 避免和缓存实例混用：缓存实例通常开 allkeys-lru，哪怕你给配置 key 加了 TTL，它也照样可能被 LRU 淘汰
• 隔离风险：配置变更失败能立刻被发现，而不是等某天某个服务读到空值才报错
• 便于观测：单独对这个实例跑 INFO memory，一眼看清配置项占多少内存，有没有异常增长
• 注意：SAVE 或 BGSAVE 仍会持久化这些 key，RDB/AOF 恢复后配置仍在

别把 noeviction 当万能保险

noeviction 只管“不删数据”，不管“数据怎么进来的”。几个容易忽略的坑：

• 如果配置 key 是通过 SET config:key "value" EX 3600 写入的，它带 TTL，那它本质是 volatile key —— 即使策略是 noeviction，过期时间一到，Redis 仍会自动删除它（这是过期策略，不是淘汰策略）
• FLUSHDB、FLUSHALL 这类命令照常执行，人工误操作照样清空配置
• 主从复制中，从库同步的是逻辑命令，不是内存快照；如果主库因 OOM 拒绝写入，从库就不会收到该配置更新
• 某些客户端 SDK（如 Lettuce）在连接池满或超时后可能静默丢弃写请求，看起来像“配置没生效”，其实根本没发到 Redis

真正关键的不是选哪个策略，而是明确：配置数据是否允许丢失、是否必须强一致、谁负责兜底重试。这些决定了你是加个独立实例，还是在应用层加一层本地缓存 fallback，而不是只盯着 maxmemory-policy 配置打转。