noeviction是金融级系统唯一可接受的内存策略，它通过写入失败显式暴露容量瓶颈，杜绝后台自动删数据；淘汰策略属兜底补救，非容量规划手段，须配合85%阈值告警、自动化扩容及oom错误处理闭环。
noeviction 是唯一能守住数据边界的策略
金融级系统对数据一致性、可追溯性、写入确定性要求极高，任何自动删除行为都可能引发账务错乱或审计断点。noeviction 不是“不作为”，而是把内存压力显式暴露为写入失败——它让业务层立刻感知到容量瓶颈，而不是让 Redis 在后台悄悄删掉某条订单、某笔流水或某个账户余额快照。
一旦启用 allkeys-lru 或 volatile-lfu 类策略，就等于授权 Redis 在内存满时自主决定“谁该消失”。而金融场景里，没有哪条 key 是天然“冷”或“低频”的：一笔 3 年前的清算日志可能在监管检查时被高频回溯；一个设置了 EXPIRE 的临时会话 token，若恰好与资金冻结状态耦合，被提前淘汰就会导致权限校验失效。
淘汰策略触发时已错过扩容黄金窗口
Redis 的淘汰机制本质是「兜底补救」，不是容量规划手段。它的触发依赖两个条件：maxmemory 被突破 + 写操作发生。这意味着：系统已在超限状态下运行了一段时间，且新请求正在挤占本该用于关键事务的内存资源。
常见误判是认为“有淘汰策略就能扛住突发流量”。但实际中：
– used_memory 接近 maxmemory 时，碎片率（used_memory_rss / used_memory）往往已升至 1.5+，真实可用空间远低于预期；
– 淘汰过程本身消耗 CPU（尤其 allkeys-lfu 需维护频率计数器），在高并发交易时段可能拖慢 SET / INCR 响应；
– 监控告警若只盯 used_memory，会漏掉 evicted_keys 计数突增这个关键信号——这已是数据开始丢失的明确证据。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
用告警+自动化扩容替代“容忍淘汰”
真正符合金融级要求的做法，是把 noeviction 和强监控绑定，形成闭环：
- 在监控系统中配置硬阈值告警：当
used_memory达到maxmemory的 85% 时触发 P1 级告警，附带最近 1 小时evicted_keys增量、mem_fragmentation_ratio趋势图 - 告警自动触发扩容流程：调用云平台 API 扩容实例内存，或向值班群推送含
CONFIG SET maxmemory建议值的工单（注意：运行时调整需确认主从同步无延迟） - 所有写入路径必须处理
(error) OOM command not allowed when used memory > 'maxmemory'错误，返回结构化错误码（如ERR_MEMORY_FULL），而非静默降级
这种设计下，内存从来不是“用完再清”，而是“用到八成就换更大容器”。淘汰策略在这里只保留一个角色：当所有防御机制失灵时，noeviction 是最后一道防止数据被篡改的闸门。
最常被忽略的一点：金融系统里，maxmemory 不能只看 Redis 自身内存，还要预留至少 20% 给 Lua 脚本执行栈、AOF 重写缓冲区、以及主从复制积压缓冲区。这些区域不计入 used_memory 统计，却一样会触发 OOM —— 此时 noeviction 同样生效，但错误日志可能指向 EVAL 或 REPLCONF，而非普通写命令。
