Redis Cluster是平滑扩展的底线选择，因其内置16384个哈希槽，支持节点增减与槽位再分配，且为官方长期维护、生产验证的唯一方案。
Redis 本身不支持“无感扩容”——所有平滑扩展都依赖客户端配合、数据迁移和流量切换，跳过任何一环都会导致请求失败或数据不一致。
为什么 Redis Cluster 是平滑扩展的底线选择
单机或主从架构无法水平分片，扩容只能靠加机器+代理（如 Twemproxy），但代理层会引入额外延迟和单点风险。Redis Cluster 内置 16384 个哈希槽，天然支持节点增减和槽位再分配，是目前唯一被官方长期维护、生产验证过的平滑扩展方案。
- 客户端必须使用支持 Cluster 协议的驱动（如
redis-py的RedisCluster类），否则会因重定向失败而报MOVED或ASK错误 - 新增节点后，必须手动执行
redis-cli --cluster reshard迁移槽位；不能只用CLUSTER ADDSLOTS，否则新节点无数据，读写直接失败 - 迁移过程中，客户端可能收到
TRYAGAIN响应——说明该槽正在迁移，需重试，不是错误，但应用层要容忍短时重试
连接池配置不当会让集群形同虚设
即使用了 Cluster 模式，如果客户端仍用普通 Redis 实例 + ConnectionPool，所有请求只会打到第一个节点，其他节点完全闲置，集群等于白搭。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须改用
redis.cluster.RedisCluster（Python）或对应语言的 Cluster 客户端类，它内置槽路由和自动重定向逻辑 - 连接池参数要调高：
max_connections建议 ≥ 50，socket_timeout设为 100–300ms，避免单个慢请求拖垮整个连接池 - 禁用
decode_responses=True在 Cluster 模式下——部分响应（如CLUSTER NODES）含二进制字段，强制解码会出错
迁移时最易忽略的三个并发陷阱
槽位迁移不是原子操作，期间读写混合会暴露一致性边界，很多线上故障就卡在这几步。
- 迁移中执行
GET可能返回旧值（源节点）或新值（目标节点），取决于重定向是否完成；若业务强依赖“读己之写”，需在应用层加短暂 sleep + 重试，或改用WAIT命令等同步机制 -
MIGRATE命令默认异步迁移 key，但若 key 很大（>1MB），迁移过程会阻塞源节点事件循环，导致其他请求延迟飙升——应提前用MEMORY USAGE扫描大 key 并拆分 - 客户端未处理
CLUSTERDOWN状态：当某个主节点宕机且无从节点接管时，对应槽位不可用，客户端应降级走 DB 或返回缓存穿透防护逻辑，而不是无限重试
真正平滑的扩展，不在于加了多少节点，而在于你是否控制住了迁移窗口期的读写行为、客户端路由逻辑和超时重试策略。这三个地方没对齐，再多的节点也救不了抖动的 P99 延迟。
