不能手动触发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 Skill - 高性能缓存管理
下载
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（非精确），淘汰顺序与真实访问时间存在偏差，压测中冷热数据混杂时尤其明显
