低配虚拟机跑Redis集群易OOM，因节点固定开销大；2GB VM应设maxmemory 1.2gb，预留300MB给复制缓冲区等，配allkeys-lfu策略、收紧ziplist阈值、禁用AOF与activedefrag。
低配置虚拟机上硬上 Redis 集群，大概率不是扩容，而是自找 OOM。集群节点本身就有固定开销（gossip 通信、复制缓冲区、连接表、slot 元数据），2GB 内存的 VM 上跑 3 个节点，每个分到 512MB，光是基础运行就可能吃掉 300MB+，根本没剩多少给业务数据。
maxmemory 必须显式设为物理内存的 60%~75%
Redis 不会自动根据宿主机内存缩放；不设 maxmemory，它就按需增长直到被系统 kill。在 2GB 虚拟机上，应直接写死：
maxmemory 1.2gb
留出至少 300MB 给 Redis 自身：复制积压缓冲区（repl-backlog-size 默认 1MB 太小，低配下建议调到 5–10MB）、AOF rewrite 临时空间、Lua 栈、客户端输入缓冲区等。设太高会触发频繁淘汰和 GC 压力；设太低则 CLUSTER SLOTS 返回失败率飙升，节点间 slot 分配卡住。
-
maxmemory-policy allkeys-lfu：比volatile-lru更稳，冷热边界模糊时更准 -
maxmemory-samples 10：提升 LFU 采样精度，避免误删热点 key - 务必关闭
notify-keyspace-events ""：每个淘汰/过期事件都额外发通知，低配下主循环直接拖慢
压缩编码阈值必须收紧，否则 ziplist 变“内存黑洞”
默认 hash-max-ziplist-entries 512 在低内存场景极危险：一个含 200 个字段的 Hash，value 平均 100 字节，实际内存占用可能超 3MB——远超指针结构体开销。必须主动压低：
hash-max-ziplist-entries 64-
hash-max-ziplist-value 64（注意：这是单个 field value 的字节上限，不是总长） -
set-max-intset-entries 128（适合用户 ID、状态码等纯整数集合） zset-max-ziplist-entries 128
改完用 MEMORY USAGE 验证是否真走压缩编码。过小会导致频繁 rehash，反而增加碎片；但宁可略保守，也别让一个 key 吃掉上百 MB。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
禁用所有非必要后台任务，把资源留给主循环
低配机器扛不住 fork 和后台线程争抢 CPU。以下几项必须关掉或弱化：
- 禁用 AOF：
appendonly no；改用 RDB +save ""（空字符串表示禁用自动快照，手动触发或靠备份策略） - 关闭 TCP keepalive：
tcp-keepalive 0（内网环境无需保活，省心跳开销） - 关闭主动碎片整理：
activedefrag no（碎片率mem_fragmentation_ratio - 缩短
cluster-node-timeout到 15000（默认 15000ms 已合理），再小易引发假故障转移；大于 20000 则 failover 迟钝
这些不是“功能阉割”，而是把有限资源聚焦在键值读写这个核心路径上。
单节点能扛住，就别拆集群
10 万~50 万键（value 小于 1KB）在单节点上完全可行，尤其配合短 key 名（如 u:1001 而非 user_profile_id_1001）、value 压缩（如 JSON 改 msgpack）、activedefrag yes（仅当碎片率 > 1.5 且内存充足时启用）。集群引入的 gossip 协议、slot 迁移、failover 选举，在低配下全是负向收益。
真正卡点从来不在“能不能分片”，而在你有没有让每个节点轻装上阵：键名够短、value 够紧、配置够克制、后台够安静。
