redis 服务器原生仅支持预定义的逐出策略（如 volatile-lru、allkeys-lfu 等），无法通过配置或插件注入用户自定义的淘汰逻辑；若需实现特定业务语义的键淘汰（如按访问时间窗口、优先级标签或业务权重），必须在客户端应用层自主设计并管理键生命周期。
redis 服务器原生仅支持预定义的逐出策略（如 volatile-lru、allkeys-lfu 等），无法通过配置或插件注入用户自定义的淘汰逻辑；若需实现特定业务语义的键淘汰（如按访问时间窗口、优先级标签或业务权重），必须在客户端应用层自主设计并管理键生命周期。
Redis 的内存逐出机制由服务端内核统一控制，其策略（如 maxmemory-policy）严格限定于官方支持的若干模式（noeviction、allkeys-lru、volatile-ttl、allkeys-lfu 等），不提供 API、模块接口或配置钩子用于注册自定义逐出算法。这是出于性能、稳定性和可预测性的核心设计考量——逐出操作需在毫秒级完成，且必须与 Redis 单线程事件循环和内存统计模型深度耦合。
因此，“自定义逐出策略”的可行路径是将淘汰决策前移至应用层，即：
✅ 主动监控 Redis 内存状态（非被动依赖 server 自动触发）；
✅ 在业务写入/读取关键路径中嵌入淘汰逻辑；
✅ 用元数据（如 ZSET 记录访问时间戳、Hash 存储权重字段）辅助决策；
✅ 调用 DEL、UNLINK 或 EXPIRE 等命令显式清理键。
以下是一个基于 Java（Lettuce 客户端）的轻量级示例，实现“按最后访问时间 + 权重衰减”的近似 LFU-LRU 混合淘汰：
// 使用 ZSET 维护「访问时间戳 × 权重」得分，score 越小越易被淘汰
public class CustomEvictor {
private final RedisClient client;
private final StatefulRedisConnection<String, String> conn;
private final String accessZSet = "zset:access_score";
public void recordAccess(String key, double weight) {
long timestamp = System.currentTimeMillis();
double score = timestamp / weight; // 权重越高，得分越低，越不易被淘汰
conn.sync().zadd(accessZSet, score, key);
}
public void evictIfOverThreshold(long maxMemoryBytes) {
// 获取当前 Redis 内存使用量（单位：字节）
String memoryInfo = conn.sync().info("memory");
long usedMemory = parseUsedMemory(memoryInfo); // 实现略，解析 info output 中 used_memory
if (usedMemory > maxMemoryBytes * 0.9) { // 触发阈值：90% 内存占用
// 淘汰最旧的 10 个键
List<String> toEvict = conn.sync().zrange(accessZSet, 0, 9);
if (!toEvict.isEmpty()) {
conn.sync().del(toEvict.toArray(new String[0]));
conn.sync().zrem(accessZSet, toEvict.toArray(new String[0]));
}
}
}
}⚠️ 注意事项：
- 避免高频轮询 INFO memory：建议结合 Redis 的 MEMORY USAGE key 对热点键精准评估，或使用 CONFIG GET maxmemory + INFO memory 做周期性检查（如每 30 秒一次）；
- 原子性保障：ZSET + DEL 非原子操作，需考虑并发写入冲突，必要时用 Lua 脚本封装；
- 过期键清理干扰：启用 lazyfree-lazy-eviction yes 可减少阻塞，但不影响应用层逻辑；
- 监控与告警：应记录淘汰频次、平均延迟及被删键特征，防止误删核心缓存。
总结而言，Redis 的“不可扩展逐出”恰是其简单性与高性能的基石。真正的灵活性不在服务端策略替换，而在于应用对缓存语义的深度建模——将业务规则（如用户等级、数据新鲜度、请求来源）转化为可计算、可排序、可持久化的元数据，并驱动主动淘汰。这不仅满足了定制化需求，更提升了缓存治理的可观测性与可控性。
