必须为每个Master节点单独且一致地设置maxmemory，因Redis集群无跨节点内存协调机制，各节点独立触发淘汰；若某节点漏配，将因无淘汰逻辑而局部OOM。

必须为每个 Master 节点单独设置 maxmemory，且所有节点值必须严格一致；否则数据倾斜会直接触发局部 OOM，不是配置遗漏，是设计硬约束。

为什么集群里改一个节点的 maxmemory 没用

Redis Cluster 不做跨节点内存协调 —— 每个 Master 只看自己 used_memory 是否超过本地 maxmemory。哪怕你只漏配一个 7004 节点（仍用默认 0），它就会持续接收写入、无淘汰逻辑、迅速爆满，而其他节点明明有空闲内存也完全帮不上忙。

• CLUSTER NODES 输出的 slot 分布只是哈希路由规则，不保证 key 数据量均匀；实际倾斜常由业务 key pattern（如 user:123:* 扎堆在某 slot）导致
• INFO memory 中的 used_memory、mem_fragmentation_ratio 全是单节点本地值，不存在“集群总内存”聚合字段
• 客户端打到哪个 slot 就落到对应 Master，淘汰动作完全隔离，不会因其他节点空闲而降低触发阈值

怎么批量统一设置所有 Master 的 maxmemory

不能只靠 redis-cli -c 连集群入口——它会自动重定向，无法保证命令落到每个物理节点。必须显式连接每个 Master 地址。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 先用 redis-cli -h NODE_IP -p PORT cluster nodes 获取完整节点列表，过滤出 master 状态且非 fail 的行
• 对每个 Master 执行两步： CONFIG SET maxmemory 4gb（立即生效，但重启丢失） CONFIG SET maxmemory-policy allkeys-lru（避免默认 noeviction 导致写失败）
• 永久生效必须同步改每个节点的 redis.conf： 在文件中添加两行：maxmemory 4gb 和 maxmemory-policy allkeys-lru，然后 systemctl restart redis
• 验证是否齐平：对所有 Master 并行执行 redis-cli -h IP -p PORT CONFIG GET maxmemory，输出值必须完全一致

maxmemory 值设多少才安全

设成物理内存 100% 是高危操作。Redis 自身开销（复制缓冲区、AOF rewrite 子进程、jemalloc 内存碎片）会额外吃掉 15%～25% 内存。

• 若节点物理内存为 32GB，maxmemory 推荐设为 24gb（75%）～27gb（85%）
• 容器部署时，cgroup memory limit 必须 ≥ maxmemory，否则容器被 kill 的错误比 Redis OOM 更难定位
• 禁用系统 swap：echo 0 > /proc/sys/vm/swappiness，防止 OS 在内存压力下把 redis-server 换出，引发超时或崩溃
• 如果已有明显倾斜，仅调 maxmemory 不够——需配合 redis-cli --cluster rebalance 重新分配 slot，但前提是 key 散列足够随机

容易被忽略的三个关键点

调完 maxmemory 后，真正决定内存是否稳住的，是这三个常被跳过的检查项：

• INFO stats 中的 evicted_keys 必须持续增长（说明淘汰策略已生效），而不是长期为 0 或突增后归零
• INFO memory 中的 mem_fragmentation_ratio 若 > 1.5，说明 jemalloc 碎片严重，需升级 Redis 或开启 activedefrag yes
• maxmemory-samples 默认是 5，对大 key 多的集群太粗糙——建议统一设为 20：CONFIG SET maxmemory-samples 20，提升 LRU 准确性，又不显著拖慢写入