redis集群各节点必须独立配置maxmemory和maxmemory-policy，因每个节点是独立进程、不共享内存状态，且key路由由crc16哈希决定，与业务语义无关；统一配策易致热点数据被误删或永久key囤积oom，须按节点实际存储数据类型（是否带ttl、是否可丢、丢哪更安全）逐个选策，并同步调优maxmemory-samples等参数。
Redis集群节点的内存回收策略不能靠“统一设定”解决——每个节点必须独立配置 maxmemory 和 maxmemory-policy，且策略选择必须匹配该节点承载的数据语义。
为什么集群里不能复用单机的淘汰策略？
集群模式下，key被哈希到不同节点，但Redis本身不感知“哪些key属于同一业务逻辑”。比如用户会话和商品缓存混在同一个slot里，如果统一配 allkeys-lru，可能刚刷进来的热点商品被会话数据挤出；而配 volatile-lru 又会导致没设TTL的会话数据永远占着内存不释放。
- 集群中每个节点是独立的Redis进程，
config set只作用于当前节点，不存在“集群级策略同步” - 客户端路由（如CRC16）决定了key物理位置，但不会把“带TTL”或“高频访问”这类语义一起路由过去
- 运维时容易误以为“配一次就全生效”，结果发现只有部分节点触发淘汰，其他节点OOM崩溃
如何为不同角色的集群节点选淘汰策略？
先看你的节点实际存什么数据，再决定策略。不是按“集群”选，而是按“这个节点上存的key有没有TTL、是否允许丢、丢哪个更安全”来定。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 纯缓存节点（所有key都带TTL）：优先用
volatile-ttl。它会优先淘汰马上要过期的key，比随机或LRU更可控，避免误杀长周期缓存 - 混合节点（部分key带TTL，部分永久存储如配置项）：必须用
allkeys-lru或allkeys-lfu（Redis 4.0+）。否则没设TTL的key永远不参与淘汰，内存只增不减 - 会话/临时状态节点（key都带TTL，但过期时间差异大）：避免
volatile-random，抽样随机性太高；volatile-lru更稳妥，至少保留最近活跃的会话 - 写密集型节点（如实时计数器）：慎用LFU，访问频次统计本身有内存开销；
allkeys-lru+ 调大maxmemory-samples（比如20）能提升淘汰准确性
配置时最容易漏掉的三个硬约束
光设 maxmemory-policy 不够，这三个参数不调好，策略根本跑不起来。
-
maxmemory必须显式设置。集群节点默认noeviction且无内存上限，一旦写满直接拒绝写入，不是自动触发淘汰 -
maxmemory-samples影响近似LRU/LFU精度。默认是5，对高并发场景太粗糙；生产建议设为10~20，但别超过30（采样耗CPU） - 使用
allkeys-lfu时，注意lfu-log-factor和lfu-decay-time的组合。factor太小（如1）会让冷数据过早被淘汰；decay-time太长（如1h）会导致热度衰减滞后
真正麻烦的从来不是选哪个策略，而是你得清楚每个节点上到底存了什么key、有没有TTL、丢了会不会影响主流程。配错策略不会立刻报错，但会在某次流量高峰时突然开始大量miss或超时——这时候再查，已经晚了。
