采样数如何影响淘汰决策
maxmemory-samples 控制近似 LRU 与近似 LFU 算法在每次淘汰时抽样检查多少个键，默认 5。采样越多，挑出的候选越接近真正的最久未用或最少使用，命中率相应更好，代价是每次淘汰的 CPU 开销上升。它不改变可用内存，只是让同样的内存装得更「有用」。当命中率瓶颈来自容量本身时，调大采样不会有明显收益。
基本信息
| 配置项 | maxmemory-samples |
|---|---|
| 默认值 | 5 |
| 建议尝试范围 | 10 附近 |
| 作用对象 | 近似 LRU / LFU 淘汰候选选择 |
| 配套项 | maxmemory-policy、maxmemory-eviction-tenacity |
| LFU 相关 | lfu-log-factor、lfu-decay-time |
| 修改方式 | CONFIG SET 即时生效，重启回配置文件 |
典型使用场景
- 缓存命中率下降但内存充足，怀疑淘汰挑错了键
- 低延迟实例容量吃紧，希望用少量 CPU 换取更准的淘汰
- 对比不同采样值下的命中率与 P99 延迟，找收益拐点
- 使用 allkeys-lru 且键访问分布不均，需要提升淘汰精度
- LFU 策略下调参，配合采样数一起评估计数衰减的影响
- 压测环境模拟线上内存水位，为参数定稿提供依据
- 新实例上线前统一淘汰参数基线，避免各环境行为不一致
- 排查缓存抖动时排除淘汰精度不足这一可能原因
调整与验证
调整与验证
redis-cli CONFIG GET maxmemory-samples # 当前采样数
redis-cli CONFIG SET maxmemory-samples 10 # 适度提高到 10
redis-cli CONFIG GET maxmemory-policy # 确认淘汰策略
redis-cli CONFIG GET maxmemory-eviction-tenacity
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'
redis-cli INFO stats | grep -E 'evicted_keys' # 淘汰活跃度
redis-cli CONFIG SET maxmemory-samples 5 # 无收益时回退默认值采样数影响对照
| 取值 | 淘汰精度 | 开销与适用 |
|---|---|---|
| 5（默认） | 近似程度一般 | 开销最低，通用场景 |
| 10 左右 | 明显更接近真实 LRU | 低延迟实例常用的折中 |
| 更高 | 精度提升有限 | 淘汰频繁时 CPU 抖动上升 |
调整后用业务指标验证收益：命中率没有提升就回退，别让参数在无人复核的状态下长期漂移。
采样数只作用于淘汰候选的挑选，键本身的内存开销、过期策略与 TTL 设计对命中率的影响通常更大。
近似 LRU 不等于精确 LRU，采样再多也只是让决策更接近理想值，不要期待命中率出现数量级变化。