Redis默认noeviction策略会引发报错，因其是写入熔断开关，内存达上限时直接拒绝所有写命令而非自动淘汰数据。

确认当前淘汰策略是否为allkeys-lru或volatile-lru

设了maxmemory-samples却没看到淘汰行为变化？大概率是因为策略根本没生效。执行：
redis-cli CONFIG GET maxmemory-policy
如果返回的是noeviction、allkeys-random或volatile-ttl，那maxmemory-samples完全不参与任何逻辑——它只在allkeys-lru和volatile-lru下被读取。Redis 5.0 不支持 allkeys-lru-v2，所以别指望策略名带版本号。

线上调参前必须盯住三个实时指标

别只看CONFIG GET返回值，关键看它是否真改变了淘汰质量：

Redis Skill - 高性能缓存管理

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

下载

• 用INFO stats查keyspace_hits / (keyspace_hits + keyspace_misses)：命中率不升反降，说明采样扩大后误伤了热 key
• 观察evicted_keys增速是否阶梯式上升，同时instantaneous_ops_per_sec同步下跌——这是 CPU 开销过载的信号
• 用redis-cli --intrinsic-latency 10测基础延迟基线，再开淘汰对比eviction-time-us的 P99 值

Redis 5.0 的淘汰耗时统计字段是eviction-time-us（微秒级），不是latency命令里的毫秒值。

maxmemory-samples设成多少才安全

默认值5在中等热度、生命周期较均匀的缓存里够用；实测升到7后，热 key 误淘汰率下降约 35%，单次淘汰仍稳定在 0.1ms 内。

• 设为10：CPU 开销可能翻倍，高并发下淘汰延迟易突破 200μs
• 设为15以上：在百万级 key 实例上，getSampleKey()调用本身会拖慢主线程，instantaneous_ops_per_sec常同步下跌
• 设为200以上：Redis 启动或CONFIG SET时静默截断为200，不报错也不警告

Redis 5.0 不支持 LFU 的频次衰减参数（lfu-log-factor、lfu-decay-time），所以别指望靠调maxmemory-samples来“救”幂律分布场景。

比调maxmemory-samples更重要的事：确认你真需要 LRU

如果业务存在明显幂律分布——比如 5% 的 key 承担 80% 请求，LRU 天然不适合：它只记“最后一次访问时间”，不记“访问频次”。这时maxmemory-samples再大也难救。

• 更直接的解法是切策略：CONFIG SET maxmemory-policy allkeys-lfu（需 Redis 4.0+，5.0 完全支持）
• allkeys-lfu对冷热分层更鲁棒，而maxmemory-samples对它的作用也转向频次估算，逻辑完全不同
• OBJECT IDLETIME 返回的是秒级估算，本身不准，别拿它验证“哪个 key 真最老”

采样精度不是万能杠杆，它撬动的是 CPU 和延迟，而不是业务语义上的“正确性”。