必须先显式设置maxmemory，否则所有淘汰策略均不生效；redis默认maxmemory为0（无限制），此时即使配置了maxmemory-policy，内存超限时也不会淘汰数据，可能导致oom killer强制终止进程。
必须先设 maxmemory，否则所有淘汰策略都不生效——这是最容易被忽略的前提。
maxmemory 必须显式设置，不能依赖默认值
Redis 默认不限制内存使用，maxmemory 值为 0，此时无论你配了什么 maxmemory-policy，都不会触发淘汰。写入持续增长最终会耗尽系统内存，可能被 OOM killer 杀掉进程。
- 配置方式：在
redis.conf中加一行maxmemory 2gb（单位支持k/m/g） - 动态生效：运行时执行
CONFIG SET maxmemory 2gb，但重启后失效 - 关键提醒：值不能设成刚好等于机器总内存，建议预留 1–2GB 给系统和 Redis 自身开销（如连接缓冲、AOF rewrite 临时空间）
volatile-lru 是缓存类业务最稳妥的起点
多数业务数据天然分两类：带 TTL 的临时缓存（如 session、token、计算结果），和不设过期时间的持久化数据（如配置、白名单）。volatile-lru 只在前者中淘汰，完全不碰后者，业务逻辑破坏风险最低。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 适用场景：用户登录态、接口限流计数、页面静态片段缓存
- 对比
allkeys-lru：后者可能误删你没设 TTL 但实际很重要的 key（比如一个全局开关 flag），而volatile-lru遇到无 TTL 的 key 直接跳过 - 注意陷阱：如果误把所有 key 都设了 TTL（哪怕设成 10 年），那
volatile-lru就退化成allkeys-lru，失去保护意义
避免用 noeviction，除非你真能容忍写失败
noeviction 是默认策略，但它不是“安全兜底”，而是“拒绝服务”。一旦内存打满，所有写命令（SET、INCR、HSET 等）都会返回 (error) OOM command not allowed when used memory > 'maxmemory'。
- 真实影响：API 返回 500、订单创建失败、用户无法登录、监控告警刷屏
- 唯一合理场景：极少数强一致性要求且有完整 fallback（如降级到 DB 写）的配置中心类服务
- 替代思路：宁可用
volatile-ttl或volatile-random保写通路，再靠业务层做兜底清理，也比直接挂掉强
采样精度影响淘汰准确性，别迷信“LRU”字面意思
Redis 的 LRU/LFU 都是近似算法，靠随机采样实现，不是精确链表。默认只采样 5 个 key（由 maxmemory-samples 控制），样本越少，淘汰越“瞎”，冷热数据区分能力越弱。
- 调高采样数（如设为 10 或 20）能提升 LRU/LFU 准确性，但会略微增加 CPU 开销
- 对高并发写入场景（如每秒上万次 SET），建议至少设
maxmemory-samples 10 - 不要盲目设到 100：实测超过 30 后收益递减，且可能在低配机器上引发明显延迟毛刺
真正影响业务的从来不是策略名字本身，而是你有没有控制住哪些 key 该有过期时间、哪些不该有，以及是否给 Redis 留出了应对突发流量的内存余量。
