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），是最稳妥的做法。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
原因很实际：
- 避免和缓存实例混用：缓存实例通常开
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 配置打转。
