redis集群节点内存必须严格一致，否则会导致数据倾斜和oom；槽位分配不等于数据均匀，需结合key散列、压测及监控优化。
Redis集群节点内存规格必须严格一致
不同节点内存差异会直接放大数据倾斜后果——哪怕只差2GB，热点槽位在小内存节点上更容易触发 OOM 或强制驱逐，而大内存节点长期闲置。这不是理论风险，是实际压测中反复复现的故障模式。
实操建议：
- 所有节点使用完全相同的物理内存（例如统一 32GB），不混用 16GB/32GB/64GB 实例
- 禁用操作系统 swap，避免
redis-server因内存不足被 OOM Killer 杀掉；检查/proc/sys/vm/swappiness必须为0 -
maxmemory配置值应设为物理内存的 75%～85%，预留空间给 Redis 自身开销（如复制缓冲区、AOF rewrite 进程）和系统缓存，不要设成 100% - 若用容器部署，务必限制
memory limit并与maxmemory对齐，否则 cgroup 内存超限时容器会被 kill，比 Redis OOM 更难排查
16384个槽位 ≠ 均匀分配到每个节点
Redis 的哈希槽（slot）是静态划分的，但数据分布是否均匀，取决于 key 的散列结果和 slot 分配策略。默认 CLUSTER ADDSLOTS 手动分配或 redis-cli --cluster rebalance 自动重平衡，都可能因 key pattern 集中导致某些 slot 数据量爆炸式增长。
实操建议：
- 重平衡前先用
redis-cli --cluster check <node></node>查看各节点 slot 数量和 key 数量，重点关注keys per slot方差大的节点 - 避免使用含时间戳、自增ID等低熵字段作为 key 主体，例如
user:123比user:20240521:123更容易打散 - 对高写入热点 key（如计数器、会话），强制加随机后缀分片：
counter:order:shard_<rand></rand>，再用HINCRBY聚合 - 不依赖自动 rebalance 处理严重倾斜——它只按 slot 数量均分，不看实际内存占用；要用
--cluster fix+ 手动MIGRATE迁移大 key
大 key 和热 key 是槽位分布失衡的放大器
一个 50MB 的 hash 结构如果落在某个 slot，就会让该 slot 对应的节点内存飙升，而其他 slot 可能全是 KB 级小 key。此时即使 slot 数量平均，内存使用也严重不均——这就是木桶效应的真实发生现场。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 上线前用
redis-cli --bigkeys扫描，单 key 超过 1MB 就要拆分或压缩；注意它只采样，需配合MEMORY USAGE精确验证 - 监控
used_memory_peak_human和used_memory_dataset_perc，前者突增说明有大 key 写入，后者长期低于 30% 说明碎片率高，需调activedefrag - 对确定的热 key（如首页 banner 缓存），改用本地缓存（
Caffeine或Guava Cache）+ Redis 降级兜底，避免所有请求打穿到同一个 slot - 禁止在集群模式下使用
KEYS *、SCAN全量遍历——它们无法跨 slot 并行，会卡死单个节点
内存与槽位规划必须同步做容量压测
只算理论槽位数量、不结合真实业务流量压测，等于没规划。某次上线前按 16384 / 6 = 2730 slot/节点分配，压测时发现 3 个节点 CPU 先跑满，另外 3 个内存才用 40%，根本原因是客户端 key hash 不均 + 部分节点网络延迟略高，导致请求集中打向少数 master。
实操建议：
- 压测必须用真实 key 分布：导出线上 1 小时访问日志，提取 key 前缀和频率，构造带权重的请求流
- 观察指标不止内存：同时盯紧
instantaneous_ops_per_sec、connected_clients、master_repl_offset增速，三者不匹配就说明负载不均 - 预留 20% slot 余量不分配，用于后续 hotkey 迁移或紧急扩容；迁移时用
CLUSTER SETSLOT <slot> IMPORTING/MIGRATING</slot>，别直接ADDSLOTS - 配置
cluster-require-full-coverage no，避免单个节点宕机导致整个集群拒绝写入——这会让木桶短板从“性能瓶颈”升级成“服务中断”
真正难的不是算清楚 16384 怎么分，而是让每个 slot 背后的 key 在时间维度和空间维度上都不扎堆。业务逻辑里的 ID 生成方式、缓存键设计、客户端 SDK 的重试策略，全都会悄悄影响这个结果。
