必须先设maxmemory，否则淘汰策略不生效；Redis默认不限制内存，未配置maxmemory时即使设置allkeys-lru等策略也无效，进程会持续吃内存直至被OOM Killer终止，生产环境须显式配置maxmemory（建议物理内存的70%～75%）与对应策略。
必须先设 maxmemory，否则淘汰策略不生效
Redis 默认不限制内存使用，maxmemory 不配置，哪怕你写了 maxmemory-policy allkeys-lru，也完全不起作用。进程会一直吃内存，直到被系统 OOM Killer 杀掉。
生产环境务必在 redis.conf 中显式设置：
maxmemory 4gb maxmemory-policy allkeys-lru
或者运行时动态设置（仅临时生效）：
CONFIG SET maxmemory 4294967296
- 单位是字节，
4gb比4294967296更不易出错 - 建议设为物理内存的 70%～75%，留足系统和其他进程空间
- 若用容器部署，还要考虑 cgroup 内存限制是否与
maxmemory冲突
allkeys-lru 是大多数缓存场景的默认安全选择
它从所有 key 中淘汰最近最少使用的，不区分是否有过期时间，适合纯缓存类业务（如页面片段、API 响应体、用户会话等）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
相比 volatile-lru，它不会因“没几个带过期时间的 key”而卡住淘汰——后者在缓存中混入大量永久 key（如配置项、白名单）时，可能触发写失败。
-
allkeys-lru在 Redis 4.0+ 中已优化为近似 LRU，性能开销可控 - 不要误以为它是精确 LRU：实际是采样 5 个 key 做比较，平衡精度与性能
- 如果业务有强访问频次差异（比如少数 key 被反复读千万次），可考虑
allkeys-lfu，但需确认 Redis 版本 ≥ 4.0
noeviction 看似保守，实则高风险
这是 Redis 默认策略，但生产缓存场景下基本不该用。它不做任何淘汰，内存满后所有写操作（SET、HSET、LPUSH）直接返回 (error) OOM command not allowed when used memory > 'maxmemory'。
问题在于：这个错误是同步抛出的，上游服务若没做好降级或重试，会导致请求链路雪崩。
- 仅适用于 Redis 当作持久化队列或状态存储（如任务调度器），且业务层能兜底写失败
- 监控上要重点盯
evicted_keys指标——如果是 0，而used_memory_peak靠近maxmemory，说明正在踩坑 - 别指望靠“加机器”绕过：集群模式下每个分片仍需独立配置
maxmemory和策略
淘汰不是后台线程，而是写操作的同步阻塞环节
每次写入触发淘汰时，Redis 主线程会暂停处理新请求，扫描候选 key 并删除，直到腾出足够空间。这意味着：淘汰耗时 = 扫描 + 删除开销，会直接抬高 P99 延迟。
尤其在 allkeys-random 或 volatile-ttl 策略下，若 key 数量极大（千万级），单次淘汰可能卡住几十毫秒。
- 避免在大 key 场景（如单个
SET存 MB 级字符串）下用allkeys-lru：淘汰一个大 key 释放的空间多，但删除本身更慢 - 用
redis-cli --bigkeys定期检查，拆分或压缩大 key - 真正影响可用性的不是“淘汰是否发生”，而是“淘汰是否可预测”——所以压测时一定要模拟内存逼近
maxmemory的场景
