redis cluster不解决小对象内存浪费，需先在单节点用hash替代string并调优hash-max-ziplist-entries（如1024）和hash-max-ziplist-value（如128）以维持ziplist编码，再通过分组（如user_hash:id%1000）控制单hash大小，方可显著降内存。
Redis Cluster 本身不解决小对象内存浪费问题
直接上 Cluster 不会自动帮你省内存——它只负责把 key 分到不同节点，而每个节点内部仍用默认编码存数据。如果你把百万个 {"id":1,"name":"a","status":0} 用 SET user:1 {...} 存成 String，Cluster 只是把这些膨胀的 JSON 均匀撒到各节点，内存还是照烧不误。
真正要省内存，得先在单节点层面把存储结构压下去：优先用 HASH 替代 SET，让字段名复用 + ziplist 编码生效；再配合合理的分组策略（比如按用户 ID 取模分到 1000 个 hash 键里），才能把内存用量从 1.8GB 降到 720MB 级别。
怎么让 HASH 在 Cluster 里保持 ziplist 编码
Cluster 节点默认配置下，HASH 很容易退化成 hashtable，失去压缩优势。必须手动调参并验证：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 改两个关键配置：
hash-max-ziplist-entries设为1024（字段固定且 ≤10 个时安全），hash-max-ziplist-value设为128（按最长字段值 ×1.5 估算，比如 email 平均 45 字节，64 就太紧） - 执行
CONFIG SET后立刻跟CONFIG REWRITE，否则重启失效 - 用
DEBUG OBJECT <key></key>检查encoding是否为ziplist，同时看serializedlength是否接近预期（比如 1000 个字段值总长 ≈ 10KB，而不是 30KB）
小对象分组映射到 HASH 的实操要点
不能随便把所有小对象塞进一个 HASH，否则单 key 过大、阻塞、迁移困难。要按业务维度做离散分组：
- 键设计：用
user_hash:123456这类格式，其中123456是分组 ID（如用户 ID % 1000） - field 设计：用短字符串，比如
n代替name、s代替status，避免冗余字符 - 控制单个 HASH 大小：每组建议 500–2000 个 field，超过就拆新 key；用
HLEN监控，避免触发 ziplist 退化 - 注意 Cluster 的 key hash tag：如果要用
{user_hash:123456}强制同 slot，得加花括号，否则分片逻辑可能把同一组打散
Bitmaps 和压缩算法不是万能解药
看到“海量小对象”就马上想 Bitmaps 或 LZF 压缩？小心踩坑：
-
BITMAPS只适用于纯 0/1 状态、ID 连续、批量统计场景（如签到、月活），存结构化对象完全不合适 -
COMPRESS命令在 Redis 7+ 才原生支持，且压缩/解压耗 CPU；对小对象（ - 真正省内存的主路径仍是：减少 key 数量 + 用 HASH + 控制 ziplist 参数 + 字段名缩写
最常被忽略的一点：上线前没跑 DEBUG OBJECT 验证 encoding，结果集群跑了一周才发现全是 hashtable，白配了参数。
