Redis集群中Pipeline不能跨slot执行，因数据按16384个hash slot分片，客户端严格校验命令key是否同slot，否则抛ClusterCrossSlotError；需按slot分组并行Pipeline或改用MSET等原生命令。
Redis集群中Pipeline不能跨slot执行，这是根本限制
Redis集群把数据按hash slot（共16384个）分散到多个节点，而Pipeline本质是一次TCP请求中打包多条命令、等待单次响应。但集群客户端（如redis-py）在启用cluster_mode=True时，会严格校验每条命令涉及的key是否落在同一slot——只要两条命令的key哈希后不属于同一个slot，Pipeline.execute()就会直接抛出ClusterCrossSlotError。
这意味着你不能像单机Redis那样，随便把GET user:1、GET order:99、INCR counter塞进一个Pipeline里发出去。不是性能问题，是协议层禁止。
- 常见错误现象：
ClusterCrossSlotError: Command # 2 (GET order:99) is not allowed on this cluster node because it contains keys from different slots - 真实使用场景：批量读取用户资料（
user:1001,user:1002...）可行；混合读用户+写日志+删缓存则大概率失败 - 绕过方法不存在——这不是配置能开的开关，是集群分片模型决定的硬约束
真正能落地的高性能读写策略：按slot聚合 + 并发Pipeline
既然不能跨slot，那就主动按slot分组。客户端拿到一批key后，先用CRC16算法算出每个key对应的slot，再按slot归类，对每一组分别创建独立Pipeline并发提交。
以redis-py为例，关键逻辑是：
# 假设 keys = ["user:1001", "user:1002", "order:555", "profile:1001"]
slot_map = defaultdict(list)
for key in keys:
slot = key_slot(key) # redis-py 内置函数，等价于 crc16(key) & 16383
slot_map[slot].append(key)
<h1>对每个slot发起独立Pipeline（可异步/线程池）</h1><p>results = {}
for slot, klist in slot_map.items():
pipe = client.pipeline(transaction=False)
for k in klist:
pipe.get(k)
results.update(dict(zip(klist, pipe.execute())))
</p>
- 注意
transaction=False：集群模式下Pipeline默认不开启事务，设为True反而可能触发重定向失败 - 性能影响：分组本身开销极小（O(n)），但并发数不宜过高——通常4~8个并发Pipeline已逼近网络和目标节点吞吐极限
- 兼容性提醒：
key_slot()在redis-py >= 4.5.0才稳定暴露，旧版本需手动实现crc16或升级
写操作高频场景下，替代Pipeline的更优选择
如果业务大量写入且key天然分散（比如日志流水号log:20240520:00001），强行分组Pipeline收益有限，还增加客户端复杂度。这时应优先考虑：
- 改用
MSET或LPUSH等原生支持多key的命令——它们内部已做slot校验，只要所有key同slot就能一次完成 - 对非强一致性场景，把写请求暂存在本地队列，按时间窗或数量阈值批量刷入，用单个
PIPELINE发给对应节点（注意别超client-output-buffer-limit） - 避免在集群中用
EVAL脚本操作跨slot key——即使Lua里用redis.call("GET", ...)也会被拦截，报错ERR Cluster mode enabled, but script tries to access keys from multiple slots
集群拓扑变更时Pipeline行为不可靠，必须重连检测
当发生reshard、failover或新增节点，集群的slot分配映射会变。此时旧Pipeline对象持有的连接可能指向已失效的节点，execute()会返回ClusterDownError或触发自动重定向——但重定向逻辑不一定覆盖Pipeline上下文，尤其在高并发分组调用中容易出现部分成功、部分失败的静默异常。
- 建议每次批量操作前，检查
client.cluster_nodes()或捕获ConnectionError/ClusterDownError后强制client.reset() - 不要复用Pipeline对象跨长时间窗口——它不感知拓扑变化，不像单机client那样“自动重连”
- 最容易被忽略的一点：某些SDK（如Lettuce）的异步Pipeline在拓扑变更后可能卡住而不报错，需配合超时和健康检查兜底
