必须升级Redis Cluster，因单机内存触顶、淘汰常态化（evicted_keys每秒>10）、命中率<0.75、内存碎片比>1.5且业务超时指向内存调度阻塞。
单机 maxmemory 触顶、淘汰策略频繁触发、keyspace_hits/keyspace_misses 比值跌破 0.8 —— 这是升级到 Redis Cluster 最明确的信号，不是“可以考虑”，而是“必须动手”。
怎么确认已经 hit 到内存硬瓶颈
别只看 used_memory_human 接近 maxmemory，关键要看淘汰是否已常态化：
-
evicted_keys在INFO stats中持续增长（比如每秒 > 10），说明 LRU/LFU 正在高频驱逐数据 -
keyspace_misses突增，且keyspace_hits增长停滞，命中率掉到0.75以下，缓存效益实质归零 -
mem_fragmentation_ratio>1.5且used_memory_rss明显高于used_memory，说明内存碎片+淘汰共同恶化了可用空间 - 业务侧出现超时集中在 GET/SET 大 Key 或高并发小 Key 场景，但
instantaneous_ops_per_sec并未打满 CPU，指向内存调度阻塞
为什么不能先加内存或换持久化策略
加内存只是延缓问题，不是解决分片本质需求：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 单机内存再大也受限于物理服务器上限（通常 ≤ 512GB），而业务数据年增长常达 TB 级
- RDB/AOF 只保数据不丢，不缓解
maxmemory触发的淘汰压力；AOF rewrite 还可能加剧内存抖动 - 开启
no-eviction？那写入会直接报(error) OOM command not allowed when used memory > 'maxmemory'，服务不可写 - 主从复制能分担读，但所有写仍压在单主，
connected_clients和blocked_clients会快速堆积
Cluster 不是唯一选项，但它是生产环境最省心的分片路径
对比其他分片方式，Cluster 在这个节点介入成本最低、长期维护负担最小：
- 客户端分片：要改所有业务代码里的
Jedis/lettuce调用逻辑，节点扩缩容时必须停机迁移 + 修改取模逻辑，shards.size()变一次，全量 Key 重哈希 - 代理分片（如 Twemproxy）：多一层网络跳转，延迟增加 0.2–0.5ms；代理本身成单点，需额外部署高可用，且不支持
multi-key命令（如MGET跨槽失败） - Redis Cluster：客户端只需启用
redis.clients.jedis.JedisCluster（Java）或redis.Cluster（Node.js），自动处理MOVED/ASK重定向；扩节点后用redis-cli --cluster reshard按槽迁移，业务无感 - 注意：Cluster 要求 Key 必须带
{...}标签才能保证 multi-key 同槽，否则MSET会报错CROSSSLOT
升级前必须验证的三个冷启动条件
Cluster 启动后无法回退为单机模式，上线前务必确认：
- 所有 Key 的命名已检查是否含有效
{和}包裹（例如user:{1001}:profile），避免CLUSTER KEYSLOT计算失准 - 业务中没用
KEYS *、FLUSHALL、SCAN全库遍历类操作 —— Cluster 下这些命令只作用于当前节点，结果不完整且易被误用 - 监控已接入
redis-cli --cluster check自动巡检，且cluster_state:ok、cluster_slots_assigned:16384两项必须为真，否则部分 slot 缺失会导致写入丢失
真正卡住人的从来不是集群搭建命令，而是 Key 设计是否适配槽路由、监控是否覆盖 slot 级别指标、以及有没有人在上线前偷偷写了跨槽事务 —— 这些细节比 redis-cli --cluster create 的参数难 debug 十倍。
