noeviction策略默认拒绝写入但不阻止过期，真正实现数据永存需确保key无TTL（TTL返回-1），并隔离配置与缓存至独立实例。
用 noeviction 策略但必须禁用所有 TTL
noeviction 不等于“数据永存”，它只拒绝淘汰，不阻止过期。只要 key 带 EX 或 PX 参数（比如 SET config:timeout "30" EX 3600），哪怕策略是 noeviction，到期后 Redis 仍会自动删除该 key——这是过期机制，和淘汰策略无关。
真正让重要数据“永远存活”的唯一方式：写入时不带任何过期时间。确认方法是执行 TTL key_name，返回值必须是 -1（永久）或 -2（key 不存在），绝不能是正整数。
- 应用层写配置时，统一走无 TTL 的
SET或HSET - 避免 SDK 自动加 TTL（如某些 Spring Cache 配置默认设了
timeToLive） - 上线前用
SCAN+TTL批量检查关键 key：redis-cli --scan --pattern "config:*" | xargs -I{} redis-cli TTL {}
独立实例比调策略更可靠
把配置类 key 和缓存类 key 放进同一个 Redis 实例，即使开了 noeviction，也解决不了根本问题：运维误执行 FLUSHDB、客户端连接错 db、主从同步中断导致从库缺失配置——这些都不是淘汰策略能拦住的。
专设一个 redis-config 实例，只允许写入 config:、feature:、region: 类 key，并配以下最小集：
-
maxmemory 64mb（够存几万条纯文本配置） maxmemory-policy noeviction-
requirepass+ 网络白名单（只允业务服务 IP 访问） - 禁用
CONFIG REWRITE、DEBUG、MODULE等高危命令（通过rename-command）
CONFIG SET maxmemory-policy 不影响已存在的 key
运行时切换淘汰策略（比如从 allkeys-lru 改成 noeviction）不会回溯清理或保护已有 key。如果之前用的是 volatile-lru，而你又给配置 key 加了 TTL，那这些 key 早已进入 LRU 淘汰队列——改策略只是让后续新写入受保护，旧隐患还在。
所以线上切策略前必须：
- 先查
INFO memory确认mem_clients_normal和mem_clients_slave是否异常高（可能有大 key 占内存） - 用
MEMORY USAGE key抽样检查核心配置 key 的实际内存占用 - 逐个执行
PERSIST key清除残留 TTL（尤其当历史配置是带过期写入的）
主从复制下 OOM 写失败会导致配置不同步
主库因内存满触发 (error) OOM command not allowed when used memory > 'maxmemory' 时，该写命令根本不会发到从库。此时主库没写成，从库自然也没更新——看起来像“主从一致”，其实是“一起漏掉”。
这不是数据被删了，而是压根没进去。监控上要盯死两个指标：
- 主库
INFO stats中的rejected_connections和evicted_keys（noeviction 下后者恒为 0，前者不该增长） - 业务侧对配置变更做写后读验证：写完立刻
GET，失败则告警并触发重试或降级 - 不要依赖从库读配置——从库只用于灾备，配置读取必须走主库
真正卡住人的从来不是策略选哪个，而是没人去确认 TTL 返回值是不是 -1，也没人定期扫 redis-config 实例里有没有混进缓存 key。
