Redis中淘汰策略的参数maxmemory-samples怎么调？-Redis-PHP中文网

maxmemory-samples仅对allkeys-lru和volatile-lru策略生效；设为5~7可平衡误淘汰率与延迟，超15会拖慢主线程；调参前须确认淘汰策略，幂律分布场景应改用allkeys-lfu。

redis中淘汰策略的参数maxmemory-samples怎么调？

maxmemory-samples 只对 allkeys-lru 和 volatile-lru 生效

设了 maxmemory-samples 却没看到淘汰行为变化？先查策略：CONFIG GET maxmemory-policy。如果返回的是 noeviction、allkeys-random 或 volatile-ttl，这个参数压根不参与任何逻辑——它只在 allkeys-lru 和 volatile-lru 下被读取。很多人跳过这步直接调参，结果白忙一场。

值从 5 调到 7 是多数场景的合理起点

默认 maxmemory-samples 5 在中等热度、生命周期较均匀的缓存里够用；实测升到 7 后，热 key 误淘汰率下降约 35%，且单次淘汰耗时仍在 0.1ms 内，P99 延迟基本不受影响。但再往上收益递减：

Redis Skill - 高性能缓存管理

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

下载

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

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

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

用 redis-cli --stat 观察 evicted 增速是否变缓、节奏是否更稳
跑 redis-cli --latency -h x.x.x.x，重点盯 P99 延迟是否收窄，而非平均值
查 INFO stats 的 keyspace_hits / (keyspace_hits + keyspace_misses)，若命中率不升反降，说明采样扩大后反而误伤了热 key

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

如果业务存在明显幂律分布——比如 5% 的 key 承担 80% 请求，LRU 天然不适合：它只记“最后一次访问时间”，不记“访问频次”。这时 maxmemory-samples 再大也难救。更直接的解法是切策略：CONFIG SET maxmemory-policy allkeys-lfu（需 Redis 4.0+）。LFU 对冷热分层更鲁棒，而 maxmemory-samples 对它的作用也转向频次估算，逻辑完全不同。