redis内存淘汰策略需匹配资源、业务与数据特征：必须显式设置maxmemory（建议服务器内存60%~70%），禁用默认noeviction；按数据ttl情况选volatile-或allkeys-类策略，调优maxmemory-samples和hz参数，并通过evicted_keys等指标闭环验证。

Redis 内存淘汰策略不是“配了就行”，而是要和服务器实际资源、业务访问特征、数据生命周期深度匹配。配置不当，轻则缓存命中率骤降、后端压力激增，重则写入阻塞、服务抖动甚至雪崩。优化关键不在堆参数，而在理解每类策略的约束条件和触发逻辑。

明确 maxmemory 是前提，不是可选项
不设 maxmemory，Redis 会持续吃内存直到被系统 OOM Killer 杀掉——这是最危险的状态。生产环境必须显式设置：

• 推荐值 = 服务器可用内存 × 0.6～0.7（预留系统、Redis 自身开销、客户端缓冲区）
• 例如 32GB 物理内存服务器，建议 maxmemory 20gb
• 设置方式：redis.conf 中写 maxmemory 20gb，或运行时执行 CONFIG SET maxmemory 20gb

按业务数据特征选策略，别默认硬套
noeviction 是默认策略，但只适合极少数强一致性场景（如 Redis 当纯持久化存储用）。绝大多数缓存场景应主动选择淘汰策略：

• 数据全部带 TTL（如会话、验证码、临时 token）→ 优先考虑 volatile-lru 或 volatile-ttl

  • volatile-ttl 适合生命周期严格固定（如 5 分钟验证码），能提前清理“即将过期”的键，减少惰性删除堆积
  • volatile-lru 更适合访问有热点（如首页 Banner 缓存），保留近期活跃的过期键

• 数据混用 TTL 和永不过期键（如部分配置热加载、部分业务缓存）→ 必须用 allkeys-* 类策略

  

  Redis Skill - 高性能缓存管理

  Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

  下载
  • allkeys-lru：通用推荐，适配大多数 Web 缓存，对时间局部性敏感
  • allkeys-lfu：适合长周期稳定热点（如商品详情页、用户基础信息），能识别“高频但非最新”的核心数据
  • 避免 allkeys-random，除非你明确接受缓存效果不可控

• 高并发秒杀/活动页等流量尖峰明显、热点高度集中 → volatile-lfu 或 allkeys-lfu 更稳

  • LFU 的频率计数器比 LRU 的时间戳更能抵抗短时噪声干扰（比如某 key 被误刷一次，不会立刻“变热”）

调优两个隐藏参数，让策略真正生效
仅设 maxmemory-policy 不够，还需配合：

• maxmemory-samples：每次淘汰时随机采样的键数量，默认 5。

  • 建议调高到 10 或 15（CONFIG SET maxmemory-samples 10）
  • 样本越多，LRU/LFU 近似精度越高，淘汰更贴近真实热度，但 CPU 开销略升

• hz：Redis 定期任务执行频率，默认 10（每秒 10 次）。影响过期键清理和淘汰触发灵敏度。

  • 高负载场景可设为 20～50（需测试 CPU 承载），让淘汰更及时
  • 注意：hz 过高会增加主线程调度压力，不建议无限制调大

监控 + 验证，闭环才叫优化
配置完必须验证是否真起作用：

• 关注指标 evicted_keys（累计淘汰数），突增说明内存持续承压
• 查看 expired_keys 和 used_memory_peak，判断是否因过期键未及时清理导致虚假“满”
• 用 OBJECT IDLETIME key 和 OBJECT FREQ key 抽样检查实际 LRU/LFU 行为是否符合预期
• 淘汰后观察后端 DB QPS 是否明显上升——若上升剧烈，说明淘汰击穿了有效缓存层

不复杂但容易忽略