如何确保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 配置打转。
