集群中maxmemory必须逐节点独立配置，因redis cluster不同步该配置，仅单点设置会导致部分节点oom；volatile-*淘汰策略在存在大量无ttl键时失效；allkeys-lfu受哈希槽分配不均影响效果打折；故障转移后内存状态与配置可能异常，需固化配置并监控验证。
集群模式下 maxmemory 配置必须逐节点独立设置
Redis Cluster 不会自动同步 maxmemory 和 maxmemory-policy 配置，每个分片（shard）都是独立的 Redis 实例，内存限制和淘汰行为互不影响。如果你只在某个节点上执行 CONFIG SET maxmemory 2gb，其他节点仍保持默认值 0（即不限制），极易导致部分节点 OOM 崩溃，而其他节点内存空闲。
实操建议：
- 必须对所有 master 节点（含未来可能扩缩容的新节点）统一执行配置，例如用脚本批量下发：
redis-cli -h {host} -p {port} CONFIG SET maxmemory 2147483648 - 不要依赖 config rewrite 自动保存——Cluster 环境下
CONFIG REWRITE可能失败或不生效，务必手动写入各节点的redis.conf并重启（或至少CONFIG SET+CONFIG GET验证） - 监控时需按节点维度看
used_memory_human和mem_fragmentation_ratio，不能只看集群总内存
volatile-* 类策略在 Cluster 中容易失效
当你使用 volatile-lru、volatile-ttl 等“仅作用于带过期时间键”的策略时，如果业务写入大量无 TTL 的 key（比如持久化用户配置、元数据），这些 key 完全不会被纳入淘汰候选集。一旦它们占满内存，策略就退化为 noeviction，后续写入全部返回 (error) OOM command not allowed when used memory > 'maxmemory'。
常见错误现象：
- 明明设置了
maxmemory-policy volatile-lru，但内存打满后写操作仍报 OOM -
INFO memory显示expired_keys很低，evicted_keys长期为 0 - 用
SCAN查出大量无 TTL 的 key（TTL key返回-1）
解决方向：
- 检查业务代码：是否所有缓存类 key 都显式设置了
EX或PX？临时数据漏设 TTL 是高频原因 - 避免混用场景：若必须存永久 key（如白名单），改用
allkeys-lru或allkeys-lfu，否则需人工定期清理 - 上线前用
redis-cli --scan --pattern "*"+TTL批量抽检 TTL 分布
allkeys-lfu 在跨节点读写不均时效果打折
allkeys-lfu 依赖每个节点独立维护 LFU 计数器，而 Redis Cluster 的哈希槽（hash slot）分配是静态的。如果某几个 slot 对应的 key 访问极度集中（比如热点商品 ID 全落在同一分片），该节点 LFU 计数器会被频繁更新，淘汰更精准；但冷数据分散在其他节点，计数器衰减慢，实际淘汰滞后。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
这会导致：
- 集群整体缓存命中率不如单机稳定
- 部分节点
evicted_keys暴涨，另一些节点内存闲置 -
lfu-decay-time（LFU 衰减周期，默认 1 分钟）在不同节点上不同步，加剧偏差
可选缓解方式：
- 调小
lfu-decay-time（如设为10秒），加快冷 key 计数器归零速度 - 配合客户端分片逻辑，把高访问密度的 key 主动打散到不同 slot（例如加随机后缀）
- 监控
keyspace_hits/keyspace_misses比率，发现倾斜节点及时 rebalance
故障转移期间淘汰行为不可控
当某个 master 节点宕机、slave 提升为新 master 后，新 master 的内存状态直接继承原 slave 的快照（RDB）。此时可能出现两种异常：
- 原 master 正在淘汰中的 key，在 slave 上尚未被删，提升后突然占用更多内存
- 新 master 的
maxmemory配置未同步（尤其通过CONFIG SET临时修改但没写 conf），导致策略回退到noeviction
关键预防点：
- 所有节点的
maxmemory和maxmemory-policy必须固化在redis.conf，不能只靠运行时CONFIG SET - 启用
cluster-require-full-coverage no，避免单点故障导致整个集群拒绝写入 - Failover 后立即检查新 master 的
CONFIG GET maxmemory*和INFO memory，确认evicted_keys是否突增
最麻烦的不是策略配错，而是你以为配了，其实只有部分节点生效，且故障后它又悄悄变回默认值。
