Redis频繁驱逐的成因与优化：降低大容量Value写入频次

Redis驱逐频繁主因是maxmemory过小或Value过大，表现为evicted_keys激增、used_memory_peak逼近maxmemory；应通过--bigkeys定位大Key、压缩/拆分Value、校验去重写入，并监控evicted_keys增速与used_memory_dataset_perc是否收敛。

Redis 驱逐频繁，大概率是 maxmemory 设置过小或 Value 过大

如果Redis启动时配置了maxmemory，比如2GB，而业务又在持续写入大体积的Value——比如序列化后的用户画像、冗长的HTML片段，或者Base64编码的图片——那么内存很快就会被顶到上限。这时，maxmemory-policy定义的驱逐策略（例如allkeys-lru）就会开始工作。这可不是什么“缓存淘汰的正常现象”，而是内存压力已经失控的明确信号。怎么判断？当监控指标evicted_keys每秒增长几十次，同时used_memory_peak又紧贴着maxmemory红线时，基本可以断定：这是大尺寸Value和高频写入共同导致的恶性循环。

遇到这种情况，可以按以下步骤排查：

• 先用redis-cli --stat实时观察evicted_keys和used_memory_human的变化节奏，看看驱逐是否集中在某类特定的key上。
• 通过redis-cli --bigkeys进行扫描，定位那些体积超过1MB的“嫌疑犯”。需要注意的是，这个命令基于采样，所以最好再用MEMORY USAGE 对可疑key进行精确验证。
• 检查业务日志，看看是否有代码在高频调用SET或HSET，写入包含大量字段的Hash结构（比如一次性写入500个用户标签）。

大 Value 写入本身会放大内存开销与阻塞风险

一个5MB的字符串Value，在Redis里实际占用的内存可不止5MB。持久化（RDB/AOF）时需要完整拷贝它，主从同步时也得整块传输。即便开启了lazyfree-lazy-eviction，驱逐时主线程虽不阻塞，但后台线程释放这么大块内存仍然需要时间。更隐蔽的风险在于，大Value会导致INFO memory中的mem_fragmentation_ratio（内存碎片率）异常升高（比如超过1.5），这意味着可用内存被碎片严重消耗，从而进一步加剧驱逐的频率。

针对大Value，有几条实用的处理原则：

• 禁止将Base64图片、过大的JSON数组（超过100KB）、未压缩的HTML等内容直接存入Redis。这类数据应该转存至对象存储，Redis里只保留其URL或ID索引。
• 使用Hash类型时要谨慎，避免通过HSET key field value单次写入大内容。可以考虑分片存储，比如按业务维度拆分成user:123:profile:part1、user:123:profile:part2等多个key。
• 对于那些必须缓存的大结构（比如推荐列表），可以先使用zstd或snappy等算法进行压缩再存储，读取时再解压。当然，需要评估压缩和解压带来的额外耗时是否在业务可接受范围内。

降低写入频次的关键是识别并拦截无效/重复写入

很多驱逐风暴并非源于真实的业务数据增长，而是源于代码缺陷。例如，某个定时任务每10秒就全量刷新一遍用户缓存，即使用户数据根本没有变化，也强制执行SET操作；或者因为接口缺乏幂等性，前端重试导致同一份大Value被反复写入多次。这类写入毫无业务价值，却实实在在地消耗着宝贵的内存配额。

要堵住这些“漏洞”，可以尝试以下方法：

• 在写入前增加一层轻量级的比对逻辑：先用GET 读取旧值，通过MD5或crc32等快速校验新旧内容是否一致，仅在内容不同时才执行SET。
• 对于定时刷新场景，可以改为“变更驱动”模式：通过监听数据库的binlog或消息队列，只在数据真正发生更新时，才触发对应的缓存更新操作。
• 为高频写入的key添加监控告警。例如，利用MONITOR命令抓取短时间（如5分钟）内的操作日志，分析SET user:*这类模式的调用来源，定位是否存在SDK或中间件的滥用行为。

业务逻辑改造后必须验证驱逐是否真正收敛

代码改完了，maxmemory调大了，或者加上了压缩，问题就真的解决了吗？未必。必须紧盯两个核心指标来验证效果：一是evicted_keys的增长速度是否已经归零，或者至少降至每分钟个位数；二是used_memory_dataset_perc（实际数据内存占比）是否稳定在70%到85%的健康区间。如果这个比例长期低于60%，则说明缓存中可能仍存在大量冗余或冷数据未被清理。

最后，还有几个容易被忽略的要点：

• 把maxmemory-policy设为noeviction并不是解决方案。这只会导致写入直接返回(error) OOM command not allowed when used memory > 'maxmemory'.错误，让业务变得完全不可控。
• 在集群模式下，单个slot中的大Value会导致该节点内存独占性飙升，而其他节点却相对空闲。此时进行横向扩容是无效的，必须优先对大Value进行拆分。
• 客户端SDK（如Jedis/Lettuce）如果开启了连接池，且maxTotal设置过小，可能会因为连接等待而间接拉长写入耗时，从而掩盖真正的性能瓶颈。