redis集群不支持跨slot pipeline，因命令需独立路由且必须同属一槽；正确做法是客户端按crc16算法预计算key槽位并分组，再对每组单独执行pipeline。

Redis集群中pipeline直接报错：MOVED/ASK重定向

集群模式下，pipeline发出去的多个命令若跨Slot，Redis服务端无法保证原子性路由，会随机返回MOVED 12345 10.0.1.2:6379这类错误——不是客户端不支持Pipeline，而是集群协议本身禁止跨节点批量执行。

根本原因是：Pipeline只是把多条命令打包发一次TCP包，但每个命令仍需独立路由；而集群要求同一Pipeline里的所有key必须落在同一个哈希槽（Slot），否则节点只能拒绝并重定向。

• 常见错误现象：redis.exceptions.ResponseError: MOVED 12345 10.0.1.2:6379 或 ASK 错误打断整个Pipeline
• 不是客户端bug，是Redis Cluster设计限制：不支持跨节点Pipeline
• 单节点Redis或Redis Sentinel下pipeline完全可用，但集群环境必须主动分组

按Slot分组pipeline的正确姿势

必须在客户端侧做两件事：先算出每个key的Slot号，再按Slot聚合命令，最后对每个Slot单独发起Pipeline。

关键点在于Slot计算不能依赖CLUSTER KEYSLOT命令查——那会引入额外RTT，且无法在发送前分组。得用和Redis服务端一致的CRC16算法本地计算。

• Python示例（用redis-py）：

  from redis.cluster import RedisCluster
  rc = RedisCluster(startup_nodes=[{"host": "127.0.0.1", "port": 7000}])
  # ✅ 正确：用rc.keyslot("mykey")获取Slot，再分组
  slot_map = {}
  for key in keys:
      slot = rc.keyslot(key)
      slot_map.setdefault(slot, []).append(key)

• Java（Lettuce）用CommandArgs.hashTag()提取tag，再调ClusterClientOptions.getHashSlot()
• 别手写CRC16——不同语言实现有细微差异，务必复用客户端库内置的Slot计算函数

多线程并发发Pipeline反而变慢？

分组后对每个Slot开一个线程发Pipeline，听起来高效，实际常掉坑里：连接池争用、线程上下文切换、小Pipeline吞吐低。

Redis集群节点数通常≤1000，但活跃Slot可能只有几十个；盲目为每个Slot启线程，容易触发连接池耗尽（如max_connections=10却开了50个线程）。

• 推荐做法：用固定大小线程池（如4–8线程），把Slot分组列表丢进去，每个线程处理多个Slot的Pipeline
• 注意pipeline.execute()是同步阻塞调用，线程数 > 节点数毫无意义
• 小批量（
• 检查客户端是否开启readonly或skip_full_coverage_check，否则某些Slot不可达时会卡住

哪些场景根本不该用Pipeline分组？

当业务逻辑天然要求跨key事务性（比如扣库存+写订单日志），又强依赖原子性，Pipeline分组解决不了问题——它只是提升吞吐，不提供跨Slot事务。

这时候要么改用Lua脚本（但Lua也受Slot限制，脚本内所有key必须同Slot），要么接受最终一致性，拆成多次单key操作加应用层补偿。

• 典型踩坑：以为“分组Pipeline + 多线程”能模拟分布式事务，结果发现部分成功部分失败，数据不一致
• 涉及keys *、scan等非确定key的命令，无法预知Slot，Pipeline分组直接失效
• 使用hash tag（如{user1001}.profile）强制key落同一Slot，是更可控的前提，否则分组逻辑会随集群拓扑变化而抖动

Slot分组不是银弹，它把问题从“命令怎么发”转移到了“key怎么设计”和“错误怎么兜底”。真正难的从来不是写几行分组代码，而是让业务key天然聚类。