redis集群中maxmemory和淘汰策略无法防止缓存击穿，因击穿发生在key过期瞬间的业务层，而内存淘汰仅在used_memory>maxmemory时触发；二者机制完全独立。
Redis集群配置maxmemory和淘汰策略，不能防止缓存击穿——击穿和内存淘汰是两套完全独立的机制。 你配得再精细，只要热点key过期瞬间没加锁或没做逻辑兜底，击穿照样发生。但配错策略会让问题更难排查、更易恶化。
为什么maxmemory-policy对缓存击穿“无感”
缓存击穿发生在业务层：一个带 EX 的 key 到期，大量请求同时 miss → 全部打 DB → 写回缓存。这个过程根本不会触发内存淘汰，因为此时 Redis 内存很可能远未触及 maxmemory。
内存淘汰只在 used_memory > maxmemory 时才启动，它管的是“空间不够”，不是“key 过期”。哪怕你用 volatile-ttl，它也不会提前删掉那个即将过期的热点 key；它只在内存真满了之后，才去 expire 字典里找“谁马上要过期”来腾地方。
真正会被淘汰策略干扰的，是击穿后的恢复阶段：比如多个请求同时重建缓存，写入一堆新 key，如果这时内存刚好逼近上限，而你又用了 allkeys-random 或 volatile-random，刚写进去的热 key 可能下一秒就被随机干掉，导致反复击穿。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
集群中必须为每个节点单独配置maxmemory
Redis 集群没有全局内存配置，每个 shard（即每个 redis-server 实例）都必须独立设置 maxmemory 和 maxmemory-policy。漏配一个节点，就可能在该节点上出现 OOM 拒写或无策略兜底。
- 动态配置（重启不保留）：
redis-cli -h 10.0.1.10 -p 7001 CONFIG SET maxmemory 4gb，再执行CONFIG SET maxmemory-policy allkeys-lru - 永久生效：修改每个节点的
redis.conf，确保包含这两行（注意单位写gb，不是g）：maxmemory 4gb<br>maxmemory-policy allkeys-lru
- Kubernetes 场景下，用
command参数传入：--maxmemory 4gb --maxmemory-policy allkeys-lru，并确保容器resources.limits.memory>4gb（否则 OS 层先 OOM Kill）
选allkeys-lru还是volatile-lru？看你的TTL分布
选错策略不会引发击穿，但会让击穿后的缓存重建变得脆弱：
- 如果你所有缓存 key 都带
EX（比如 session、token、商品页），用volatile-lru更安全：它只动带过期时间的 key，不会误删你可能混存的永不过期配置项 - 如果你有部分 key 没设 TTL（如用户中心元数据、灰度开关），却配了
volatile-lru→ 实际可淘汰 key 极少 → 内存持续上涨 → 最终 fallback 到noeviction→ 写缓存失败 → 新建的 key 写不进去 → 击穿后无法恢复 -
allkeys-lru是通用兜底选择，但要求你确认：所有 key 都可丢。否则就得靠应用层保证关键数据不进 Redis，或改用noeviction+ 监控告警提前干预
最容易被忽略的三个硬性前提
淘汰策略生效前，这三个条件缺一不可，任一缺失都会让配置形同虚设：
-
maxmemory必须显式设置为正整数（如2gb），默认值0= 不限制内存 → 淘汰开关永远关闭 -
maxmemory-policy不能是默认的noeviction，否则超限直接报(error) OOM command not allowed when used memory > 'maxmemory'，而不是自动清理 - 单位必须合法：
2g会被 Redis 当作 0 处理，2048m会被解析成 2048 字节 —— 唯一推荐写法是2gb、512mb
配完别忘了验证：redis-cli CONFIG GET maxmemory 和 CONFIG GET maxmemory-policy 输出必须是你设的值，且 INFO memory 中的 mem_used_human 要明显低于 maxmemory_human，否则策略根本没机会运行。
