Redis没有eviction-tenacity配置项；其淘汰机制由maxmemory-policy、maxmemory和maxmemory-samples三者协同控制，核心在于合理设计key生命周期与数据结构而非盲目调参。
Redis 本身没有 eviction-tenacity 这个配置项——它不存在于任何 Redis 版本中，官方文档、源码、配置文件模板里都搜不到。你看到的这个参数，大概率是混淆了其他系统（比如某些自研缓存中间件或过时的博客误传）的概念。
Redis 淘汰策略实际生效的控制点只有三个
真正影响“大批量写入时淘汰是否跟得上”的，是以下三者协同作用的结果，缺一不可：
-
maxmemory-policy：必须设为allkeys-lru、volatile-lfu等主动淘汰策略，noeviction下写入直接报(error) OOM command not allowed when used memory > 'maxmemory'. -
maxmemory：硬上限，超过后才触发淘汰；设得太低会导致频繁驱逐，设得太高则内存溢出风险上升 - 淘汰执行时机与粒度：Redis 不是“每写一个 key 就淘汰一个”，而是在每次写命令前检查内存，超限时执行一次 批量采样淘汰，采样数由
maxmemory-samples控制（默认 5）
maxmemory-samples 调大能缓解“淘汰跟不上”吗？
能，但有明确边界和副作用。它决定每次淘汰循环随机抽查多少个 key 来评估“谁该走”。默认值 5 太保守，尤其在 key 大量集中于某几种 TTL 或热度分布不均时，容易漏掉该淘汰的冷 key。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 写压测中观察
evicted_keys和expired_keys的增长速率差——如果前者远低于后者，说明采样不足，冷 key 淘汰滞后 - 可逐步调高
maxmemory-samples到 10～20（注意：不是越大越好） - 超过 30 后，单次淘汰耗时明显上升，可能拖慢写入响应（尤其在小内存实例上），且边际收益急剧下降
- 配合
INFO memory中的mem_allocator和used_memory_rss对比，确认是否因内存碎片导致used_memory虚高、误触发淘汰
更有效的应对方式：避开淘汰瓶颈本身
与其强行提升淘汰“硬度”，不如减少淘汰压力来源。大批量写入 + 淘汰跟不上的典型场景，往往暴露的是使用模式问题：
- 批量写入前没做 key 生命周期规划：全部设 long TTL 或永不过期，导致冷热混杂。应按业务 SLA 区分
SET key val EX 3600和SET key val PX 60000 - 用
LPUSH/RPUSH做日志堆积，却未配LTRIM截断——这类结构应改用带自动裁剪的XRANGE+XADD流或外部队列 - 客户端未启用 pipeline，导致网络往返放大淘汰检查次数；高吞吐写入务必用
redis-py的pipeline.execute()或redis-cli --pipe - 集群环境下，
maxmemory是节点级限制，但数据倾斜会让个别节点提前爆满——需用redis-cli --cluster check验证 slot 分布
真正卡住的从来不是“单次淘汰够不够狠”，而是“为什么每次都要淘汰”。maxmemory-samples 只是止痛药，key 设计、写入节奏、数据结构选型才是病根。调参前先抓一次 MEMORY USAGE 和 SCAN 抽样，看看 top 20 大 key 是什么类型、有没有僵尸 key——这比找一个不存在的 eviction-tenacity 实在得多。
