Redis集群内存开销显著高于单机，因每个节点需维护16384个槽位的完整映射表、独立复制积压缓冲区、多连接输出缓冲区及更高内存碎片率。
集群模式下每个节点都要维护槽位映射表
Redis集群不是简单把数据打散就完事，每个节点必须完整保存整个集群的槽位分配信息（16384个槽位谁管哪一段），这部分元数据存在内存里，不随数据量线性增长，但固定占用几MB。单机 Redis 完全没有这个负担。
常见错误是误以为“只是多几个 key”，其实 cluster slots 返回的每条记录都对应一个内存结构体，包含起始槽、结束槽、主节点 ID、从节点 ID 列表等字段。6 主 6 从集群中，每个节点要存至少 6 条主节点记录 + 多条从节点记录，加起来远超单机的 dict 或 redisDb 开销。
- 可通过
info cluster查看cluster_stats_messages_sent和cluster_stats_messages_received增长是否异常，间接反映元数据同步压力 - 升级到 Redis 7+ 后，
cluster-node-timeout调得过大（比如 > 15000）会导致节点间心跳消息堆积，缓冲区持续增长
客户端连接数翻倍带来输出缓冲区膨胀
集群模式下，客户端通常要跟多个节点建立连接（哪怕只读写一个 key，也可能因重定向或 MOVED/ASK 响应触发新连接）。每个连接都有独立的输出缓冲区（output_buffer），而 monitor、订阅客户端、慢消费客户端会把缓冲区撑满，直接吃掉几十 MB 内存。
单机模式下，所有请求走一个端口，连接池收敛好；集群里，JedisCluster 默认为每个节点维护独立连接池，且不会自动复用跨节点连接 —— 这意味着 6 主节点可能同时存在 6×maxTotal 连接，每条连接的 client_longest_output_list 都在涨。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
client list检查时重点关注omem=字段，值 > 1048576（1MB）就要警惕 -
redis-cli -h node1 -p 6379 client list | grep "omem=[1-9][0-9]*"可快速过滤高缓冲区连接 - 禁用
monitor是最立竿见影的手段，生产环境绝不该开启
复制积压缓冲区（repl-backlog）按节点独立配置
单机主从只需一份 repl-backlog-size，而集群中每个主节点都有一份自己的积压缓冲区。如果集群有 6 个主节点，且你设了 repl-backlog-size 10485760（10MB），那光这一项就固定多占 60MB 内存，还不算从节点的复制缓冲区。
更麻烦的是，集群里从节点可能同时作为其他主节点的从节点（比如 A 主 ← B 从，B 主 ← C 从），导致同一块内存被多次计入不同节点的 used_memory 统计，监控上看就是“总内存 > 所有节点内存之和”。
- 检查方式：
info replication中的repl_backlog_active和repl_backlog_size - 若业务写入节奏稳定、网络延迟低，可将
repl-backlog-size从默认 1MB 降到 512KB，6 节点省下 3MB × 6 = 18MB - 注意：调太小会导致从节点断连重连时触发全量同步（
psync fullresync），反而更伤内存和带宽
内存碎片率在集群中更容易被放大
集群节点各自进行 bgsave 或 bgrewriteaof，fork 子进程时机错开，导致内存分配器（jemalloc）的碎片无法对齐清理。单机一次 fork 可能释放大片连续内存，集群里 6 个节点轮流 fork，碎片像毛玻璃一样越积越厚。
现象是 used_memory 看着不高，但 mem_fragmentation_ratio > 1.5，且 used_memory_rss 远高于 used_memory —— 这说明操作系统分配的物理内存远超 Redis 实际使用的逻辑内存。
- 用
memory doctor查问题根源，它会提示 “High memory fragmentation” 并建议memory purge - 但
memory purge不是万能药：jemalloc 在 Linux 上需内核支持MADV_DONTNEED，老版本系统可能无效 - 真正治本是控制单节点数据规模，避免单节点
used_memory> 16GB，降低 fork 压力
client list 和 info memory 的交叉比对 —— 很多时候多出来的几百 MB，就卡在某个没关的 monitor 或者漏配的 client-output-buffer-limit 上。 
