不能手动触发redis淘汰策略,需通过内存填充+写命令超限迫使performevictions执行;del等删除操作不触发淘汰,仅写命令在used_memory>maxmemory时才进入淘汰流程。

不能直接“手动触发”Redis内置淘汰策略的执行过程,但可以通过控制内存填充 + 强制触发eviction循环来逼近真实淘汰行为。关键不是调用某个函数,而是让performEvictions被实际调用并完成一轮淘汰。
为什么EVAL脚本里调redis.call("del")不算“触发淘汰”
很多人误以为在Lua里删key就是在模拟淘汰——其实不是。Redis的淘汰(eviction)只发生在写命令导致内存超限后、命令执行前的检查阶段,由performEvictions函数驱动。单纯del只是普通删除,不走淘汰路径,也不受maxmemory-policy影响。
-
del、flushdb等是主动清理,和淘汰机制无关 - 淘汰必须伴随“写入压力”:比如
set、hset、lpush等可能增加内存的命令 - 只有当
used_memory > maxmemory且当前命令属于“写类”时,才会进入淘汰流程
怎样构造可复现的淘汰压力测试场景
核心思路:先填满内存到略低于maxmemory,再用一个写命令精准突破阈值,迫使Redis执行一次淘汰循环。整个过程需可控、可观测。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 确认当前
maxmemory值:CONFIG GET maxmemory,比如返回104857600(100MB) - 用
DEBUG POPULATE快速填充(仅开发/测试环境):DEBUG POPULATE 50000 keyprefix 1024→ 生成5万条1KB的key - 或用Lua脚本逐步填充(更贴近真实业务):
eval "for i=1,10000 do redis.call('set', 'testkey:'..i, string.rep('x', 512)) end" 0 - 执行
INFO memory观察used_memory是否已达95%+,再发一个set bigkey "x"..string.rep("y", 20000)触发超限
用Lua脚本模拟“边写边淘汰”的连续压力
单次触发只能验证是否能淘汰,但压测要看持续淘汰下的表现(如QPS下降、延迟毛刺、命中率变化)。下面这个脚本会循环写入并观察是否发生淘汰:
for i = 1, 1000 do
-- 写入一个约1KB的key,大概率触发淘汰检查
redis.call("set", "pressure:"..i, string.rep("v", 1024))
-- 每100次查一次内存,避免太频繁干扰
if i % 100 == 0 then
local mem = tonumber(redis.call("INFO", "memory"):match("used_memory:(%d+)"))
if mem and mem > 100000000 then -- 超过100MB
redis.call("incr", "eviction_triggered")
end
end
end
return "done"
- 该脚本不保证每次
set都触发淘汰,但高概率下performEvictions会被调用多次 - 注意:脚本中不能调用
redis.call("CONFIG SET maxmemory ..."),Lua沙箱禁止运行配置类命令 - 若想监控淘汰数量,应依赖
INFO stats中的evicted_keys字段,而不是脚本内计数
最容易被忽略的三个细节
实际压测时,以下三点常导致结果失真,却很少被检查:
-
maxmemory单位是字节,但INFO memory里used_memory_human是带单位的字符串,解析时别直接比对"100MB" - 启用
AOF或RDB时,fork子进程会额外占用内存(copy-on-write),可能导致“明明没写多少数据却触发淘汰” -
allkeys-lru在Redis 7.0+默认使用近似LRU(非精确),淘汰顺序与真实访问时间存在偏差,压测中冷热数据混杂时尤其明显










