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 延迟。