直接用 pipeline 写 Redis 集群会报 ASK 或 MOVED 错误，因为客户端未按 slot 分组发送命令，导致请求被发往错误节点；需先获取集群拓扑、按 slot 分组 key、对每个 slot 对应节点单独建 pipeline，并预热 slots map 以避免拓扑变更引发重定向。
为什么直接用 pipeline 写 Redis 集群会报 ASK 或 MOVED 错误
Redis 集群模式下，key 不是均匀散列到所有节点，而是先通过 CRC16(key) % 16384 算出槽位（slot），再由集群分配槽到具体节点。客户端如果像单机一样把一批 key 塞进一个 pipeline 发给任意节点，该节点发现某些 key 不归自己管，就会返回 MOVED 重定向响应——而多数基础客户端（比如 Jedis 默认配置、redis-py 的非 cluster 模式）不自动处理重定向，直接抛异常或静默失败。
常见错误现象包括：
redis.exceptions.ResponseError: MOVED 12345 10.0.1.5:6379-
redis.exceptions.ResponseError: ASK 12346 10.0.1.6:6379（发生在迁移中） - 写入成功率忽高忽低，部分 key 永远没进集群
必须按 slot 分组，再对每个 slot 对应节点单独建 pipeline
核心做法是：先获取集群拓扑（CLUSTER SLOTS 或客户端自动刷新的 slots map），把待写 key 按 key → slot → node 映射分组，每个分组内 key 发往同一节点，并复用该节点的 pipeline。
实操要点：
- 不要手动硬编码 slot 计算逻辑，用客户端内置方法（如 redis-py 的
key_slot()、JedisCluster 的getSlot(key)）避免 CRC16 实现差异 - 分组后，每个节点 pipeline 最好限制长度（例如 100–500 条命令），防止单次请求过大超时或 OOM
- 注意连接复用：对同一节点多次 pipeline 调用，应复用同一个 connection（或 connection pool 中的同类型连接），避免反复建连开销
- 若使用 Jedis，务必用
JedisCluster实例而非Jedis；若用 redis-py，必须用RedisCluster（来自redis-py-cluster或新版redis4.0+ 的redis.RedisCluster）
批量写入前先预热 slots map，避免 pipeline 过程中拓扑变更
集群扩缩容、failover 或 slot 迁移时，slots map 会动态变化。如果 pipeline 执行期间 map 刷新，可能导致某批 key 被发到旧节点，触发 ASK 或写入丢失。
安全做法：
- 在批量任务开始前，主动调用一次
cluster_slots()（redis-py）或getClusterNodes()（JedisCluster）拉取当前完整拓扑 - 禁止在 pipeline 循环中实时查 slot —— 这会极大拖慢速度且增加网络抖动风险
- 若业务允许短暂延迟，可在任务启动时加锁或标记“拓扑冻结”，配合运维窗口避开迁移操作
示例（redis-py）：
from redis.cluster import RedisCluster<br>rc = RedisCluster(startup_nodes=[{"host": "10.0.1.1", "port": "6379"}], decode_responses=True)<br># 预热并缓存 slot 映射<br>rc.initialize_slots_cache()<br># 后续 key_slot() 就走本地缓存
大 key + pipeline 组合容易触发 cluster-node-timeout 或内存 spike
不是所有“批量写”都适合无脑上 pipeline。当单个 key value 超过几 MB，或单 pipeline 包含大量 HSET/LPUSH 命令时，节点可能因单请求处理时间过长被判定为失联，或引发内存瞬时飙升。
需权衡与拆分：
- value > 1MB 的 key，优先考虑拆成小 key（如用
HSET分字段）或换用SCAN + MSET分片写入 - 单 pipeline 命令数建议 ≤ 200，总数据量 ≤ 1MB；可通过
len(pipeline.command_stack)和累计序列化长度做硬限 - 监控指标重点看：
cluster_stats_messages_sent（确认是否真发到了目标节点）、used_memory_peak（节点内存尖峰）、rejected_connections（连接拒绝数）
真正卡点不在“会不会 pipeline”，而在“有没有把 slot、拓扑、单请求负载三者对齐”。漏掉任一环，吞吐量反而比逐条写还低。
