保证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，一眼就能看出配置项占用多少内存，是否存在异常增长
• 注意：SA VE 或 BGSA VE 仍会持久化这些 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 配置打转。