淘汰策略选错会导致写入延迟飙升：allkeys-lfu等复杂策略或maxmemory-samples设置不当会显著增加单次写入开销，volatile-ttl因仅比对ttl值而吞吐更高；evicted_keys持续>100/秒或mem_fragmentation_ratio>1.5时需及时排查策略与数据模式匹配性。
淘汰策略选错会导致写入延迟飙升
当 maxmemory 触发后，Redis 每次写操作都要先执行淘汰逻辑，这个过程不是零开销。如果策略本身计算复杂（比如 allkeys-lfu），或候选键数量大但 maxmemory-samples 设置过小，就会反复采样、比对、删除，拖慢单次写入响应。实测中，volatile-ttl 在大量短期 key 场景下吞吐量比 allkeys-lru 高 15%~20%，因为它只比 ttl 值，不维护访问时间或频次计数器。
-
allkeys-lfu会为每个 key 维护一个 16-bit 的访问频次计数器，且需衰减处理，CPU 开销明显高于 LRU 类策略 -
volatile-random和allkeys-random几乎无计算成本，但缓存命中率可能骤降，间接导致后端压力上升，整体吞吐反而下降 - 若用
noeviction且未配监控告警，写请求直接返回(error) OOM command not allowed when used memory > 'maxmemory'，应用层重试逻辑会放大延迟毛刺
maxmemory-samples 参数直接影响淘汰效率与公平性
Redis 不是遍历全部 key 做淘汰，而是每次随机采样 maxmemory-samples 个键（默认 5），再从中挑出最该淘汰的那个。这个值太小（如设为 1），容易误删热点 key；太大（如设为 200），单次淘汰耗时增加，尤其在 key 总数超千万时，采样本身就成了瓶颈。
- 生产环境建议从 10 起调：
maxmemory-samples 10是吞吐与准确性的常见平衡点 - 若业务 key 访问呈强幂律分布（少数 key 占 80% 流量），可适当提高到 15~20，让 LFU/LRU 更大概率捕获真实冷 key
- 注意：该参数只对
*-lru、*-lfu、volatile-ttl生效，*-random策略完全忽略它
evicted_keys 指标异常高说明策略与数据模式不匹配
通过 INFO memory 查看 evicted_keys 累计值，如果每秒淘汰数持续 > 100，就要警惕了——这不是“正常释放”，而是策略在反复救火。常见原因包括：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用了
volatile-lru，但大部分 key 没设过期时间，实际无键可淘汰，写操作被阻塞后重试，触发更多淘汰尝试 - 用了
allkeys-lru，但业务存在大量短生命周期 key（如 session token），LRU 无法识别“刚写入就该删”，反而保留低频长周期 key - 内存碎片率
mem_fragmentation_ratio> 1.5，真实可用内存不足，导致淘汰频率虚高
此时应先运行 MEMORY USAGE 定位大 key，再结合 OBJECT freq 查看 key 访问热度，而非直接调高 maxmemory。
LFU 策略的衰减机制容易被忽略
allkeys-lfu 或 volatile-lfu 不是单纯计数。Redis 会对频次计数器做定时衰减（默认每分钟一次），防止历史高频 key 长期霸占内存。但衰减周期和幅度不可配置，这意味着：
- 如果业务有明显的日周期流量峰谷（如早 8 点突增），LFU 可能还没来得及衰减就进入高峰，误判旧 key 仍为热点
- 新 key 初期访问频次低，但 LFU 计数器起始值不是 0（最小为 5），冷启动阶段容易被误保留在内存
- 相比 LRU，LFU 对突发流量更敏感：一个 key 短时被刷 100 次，计数器可能冲到上限，之后衰减也难回落，长期占据位置
真正需要 LFU 的场景，必须确认访问模式稳定、热点收敛快，否则 allkeys-lru 或 volatile-ttl 往往更稳。
