maxmemory-samples控制Redis在LRU淘汰时每次随机采样的key数量，默认5，值越大淘汰越接近理想LRU但CPU开销线性上升，最大限制为200；仅对allkeys-lru或volatile-lru策略生效，调优需结合evicted_keys速率、缓存命中率及延迟监控，必要时可切换至allkeys-lfu策略。
Redis的maxmemory-samples到底控制什么
它不改变LRU算法本身，只决定每次淘汰前随机采样多少个key来估算“最久未使用”的候选。默认值5意味着：内存满时，Redis从所有key中随机挑5个，比对它们的空闲时间（idle），选其中最大的那个删掉——不是真遍历全部key，所以是近似LRU。
调高maxmemory-samples能变“更准”，但代价明显
增大采样数会让淘汰行为更接近理想LRU，尤其在key访问模式有局部性偏差时（比如一批冷数据长期没被访问，但恰好没被抽中）。但要注意：
- 每次淘汰操作的CPU开销线性上升，
maxmemory-samples设成20，耗时可能比5高3倍以上 - 在高并发写入+频繁触发淘汰的场景下，可能加剧延迟毛刺，
INFO stats里的evicted_keys和expired_keys突增时要同步看instantaneous_ops_per_sec -
maxmemory-samples最大只支持200，设更大值会被Redis启动时静默截断为200，且不会报错
什么时候该调、怎么调才安全
别一上来就改配置。先确认是否真有问题：
- 观察
INFO memory里的mem_eviction_policy是不是allkeys-lru或volatile-lru（只有这两个策略才用到这个参数） - 查
INFO stats中的evicted_keys速率，如果每秒淘汰几百个以上，且业务感知到缓存命中率异常下跌，再考虑调优 - 线上调整建议用
CONFIG SET maxmemory-samples 10（不重启），然后盯5分钟latency doctor和慢日志，没抖动再逐步加到15；超过15必须做压测
注意：LRU不是唯一选项，allkeys-lfu可能更合适
如果你的热点数据有明显访问频次分层（比如少数key被反复读，多数key只读一次），maxmemory-samples再调也救不了LRU的先天缺陷。这时候换策略更直接：
-
CONFIG SET maxmemory-policy allkeys-lfu（需Redis 4.0+） - LFU依赖访问频次计数器，
maxmemory-samples对它作用变小——采样是为了估算频次，不是空闲时长 - 但LFU有冷启动问题：新key初始计数低，容易被误删，可通过
lfu-log-factor和lfu-decay-time微调，这又是另一回事了
redis-cli --stat输出的实时淘汰节奏，而不是理论上的“越准越好”。采样精度只是杠杆的一端，另一端压着的是你的CPU和延迟预算。 
