redis集群节点内存配置需显式设置maxmemory为物理内存的60%~75%，并预留至少300mb供自身运行；小数据量场景下，单节点可承载10万~50万键，无需强行部署集群。
集群节点内存配置不能只看总容量
Redis集群不是“把数据平分就完事”，每个节点仍需独立管理内存。低配服务器（比如单节点仅2GB内存）上，若盲目启用集群，反而因slot迁移、复制缓冲区、客户端连接表等额外开销导致OOM。关键不是总内存多大，而是maxmemory必须显式设为物理内存的60%~75%，且要留出至少300MB给Redis自身运行（含复制积压缓冲区、AOF rewrite临时空间、Lua脚本栈等）。maxmemory设太高，触发淘汰时GC压力陡增；设太低，CLUSTER SLOTS返回的哈希槽分配会频繁失败。
小数据量场景下，别硬上集群
集群本质是为水平扩展设计的，但低配环境下，单节点扛住10万~50万键（取决于value大小）完全可行。如果业务QPS allkeys-lfu淘汰策略+activedefrag yes，比拆成3个512MB节点更稳。集群引入的gossip协议通信、failover选举、slot迁移都会吃掉可观CPU和内存——尤其在cluster-node-timeout设得偏小时，心跳包堆积易触发假故障转移。
压缩编码参数必须重调
默认配置对低配环境极不友好：hash-max-ziplist-entries默认512，但一个含100字段的Hash在低内存下可能已占几MB。应主动收紧阈值：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
hash-max-ziplist-entries 64（而非512） -
hash-max-ziplist-value 64（而非64字节，指单个field value长度上限） -
set-max-intset-entries 128（整数集合更紧凑，适合ID类数据） zset-max-ziplist-entries 128
这些调整能让更多数据走ziplist或intset编码，减少指针内存开销。但注意：过小会导致频繁rehash，可用MEMORY USAGE命令验证单个key是否真用了压缩编码。
淘汰策略选allkeys-lfu比volatile-lru更靠谱
低配机器上，冷热数据边界模糊，volatile-lru依赖TTL，但很多缓存根本没设过期时间；allkeys-lfu按访问频次淘汰，更适合真实负载。搭配maxmemory-samples 10（默认5），能提升LFU采样精度，避免误杀热点key。但务必关掉notify-keyspace-events——它会为每个过期/淘汰事件生成额外事件通知，低配下极易拖慢主循环。
真正卡点不在集群本身，而在你是否让每个节点“轻装上阵”：短键名、压缩value、禁用AOF（改用RDB+save ""）、关闭tcp-keepalive（内网环境无需保活）。集群只是分片手段，内存优化永远从单节点开始。
