volatile-lru策略仅淘汰带ttl的key，需确保缓存统一设ttl、合理设置maxmemory（参考峰值上浮15%~20%并预留系统开销）、调大maxmemory-samples至10~20提升淘汰精度，并辅以定期清理和evicted_keys告警形成闭环。
调优 Redis 的 maxmemory 与 volatile-lru 策略，核心在于让内存上限设置合理、淘汰行为可控、且不干扰业务关键数据。重点不是盲目加大内存，而是让 Redis 在压力下仍能稳定写入、保留热点、快速响应。
明确 volatile-lru 的适用边界
volatile-lru 只作用于设置了过期时间（TTL）的 key。如果大量缓存未设 TTL，该策略将“无键可删”，内存超限后直接退化为 noeviction 行为——所有写操作报错 OOM command not allowed。
- 检查当前 key 的过期设置比例：
redis-cli --bigkeys或redis-cli info keyspace查看各 DB 中带 TTL 的 key 数量 - 确保业务写入缓存时统一加 TTL，例如：使用
SET key value EX 3600而非SET key value - 避免混用
volatile-*策略与永久存储型 key（如配置项、用户白名单），这类 key 应迁移到独立实例或改用allkeys-lru+ 逻辑隔离
科学设置 maxmemory 值
不能只看物理内存余量，需结合 Redis 内存碎片率（mem_fragmentation_ratio）和实际 used_memory 增长趋势设定。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 通过
INFO memory观察used_memory_peak和近 1 小时内存波动，取峰值上浮 15%～20% 作为初始maxmemory - 若部署在容器或资源受限环境，建议预留至少 25% 内存给系统与 Redis 自身开销（如复制缓冲区、AOF rewrite 进程）
- 示例：实测高峰
used_memory为 1.6GB，碎片率 1.3，则建议设maxmemory 2gb，而非直接设为 2.1GB 物理上限
增强 volatile-lru 的淘汰精度
Redis 的 LRU 是近似实现，靠采样而非全量扫描。默认 maxmemory-samples 5 容易漏掉冷 key，尤其在 key 总数达百万级以上时。
- 将
maxmemory-samples提升至 10～20（动态生效）：CONFIG SET maxmemory-samples 15 - 配合监控：观察
evicted_keys指标突增是否伴随keyspace_hits / keyspace_misses显著下降，判断是否误删了高频访问的过期 key - 若发现淘汰后命中率骤降，说明样本量仍不足或存在“伪热点”（如短 TTL + 高频刷写），此时应考虑改用
volatile-lfu（Redis 4.0+）更适配访问频次模式
搭配定期清理与告警闭环
策略本身是兜底机制，不能替代主动治理。
- 每天低峰期执行
SCAN+TTL批量识别长期未更新但仍有 TTL 的“僵尸缓存”，主动DEL - 在 Prometheus + Grafana 中配置告警：当
evicted_keys1 分钟内增长 > 1000 或rejected_connections> 0 时立即通知 - 记录淘汰日志（需开启
loglevel notice及以上）：关注 “Evicting expired key” 与 “Evicting key by volatile-lru” 的比例，失衡即提示 TTL 设计不合理
