如何防止Redis配置信息被自动淘汰：独立实例或noeviction策略

如何保证Redis重要配置信息不被自动淘汰

先给出核心结论：重要配置信息不会被自动淘汰——前提是它不在淘汰范围内，或者Redis根本没有机会触发淘汰机制。以下分场景详细说明。

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

核心思路有两种：要么将配置key存放在一个永远不会被驱逐的独立空间中，要么让Redis在内存满时直接拒绝写入——而非悄悄删除关键数据。前者依赖独立实例，后者依赖noeviction策略。

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

换言之，noeviction 提供了一个明确的失败信号，而非让技术人员事后排查“某个 key 为何消失”。

独立实例比策略更可靠，但需资源投入

使用一个专用于存储配置的 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，即使策略为 noeviction，过期时间到达后 Redis 仍会自动删除该 key（这是过期策略，并非淘汰策略）
• FLUSHDB、FLUSHALL 等命令照常执行，人工误操作同样会清空配置
• 在主从复制场景中，从库同步的是逻辑命令而非内存快照；若主库因 OOM 拒绝写入，从库不会收到该配置更新
• 某些客户端 SDK（如 Lettuce）在连接池满载或超时后可能静默丢弃写请求，导致“配置未生效”，实际并未发送到 Redis

真正关键的并非单纯选择哪个策略，而在于明确：配置数据是否允许丢失、是否必须强一致、由谁负责兜底重试。这些因素决定了是部署独立实例，还是在应用层增加本地缓存 fallback，而不是仅围绕 maxmemory-policy 配置打转。