Redis集群模式不支持哪些命令？命令规则与客户端兼容问题

2023年更新提示：Vert.x Redis目前已经原生支持SCAN命令，但存在已知未修复Bug，生产环境使用前需要充分验证稳定性。

报错原因：为什么集群模式下KEYS可执行但SCAN最初报错 #

你遇到的scan not supported - use non cluster client on the right node报错，本质是客户端封装逻辑的差异，和Redis服务端本身无关：

• 原生Redis集群没有提供任何跨节点全局遍历的服务端能力，不管是全局KEYS还是全局SCAN，都不是Redis集群原生支持的功能。
• 早期Vert.x Redis集群客户端专门给KEYS命令做了适配：客户端自动拉取集群所有节点列表，逐个给节点发送KEYS请求，最后把所有节点的返回结果聚合后给调用方，造成了「集群支持全局KEYS」的假象。
• 当时版本的客户端没有给SCAN命令做这套逐节点遍历、游标续接、结果聚合的逻辑，所以直接抛出错误，提示用户手动连接单节点执行。

Redis集群命令支持的明确判定标准 #

集群规范里提到的「支持所有单键命令」，判定逻辑非常清晰，没有模糊空间：

• 单键命令：命令只操作一个key，客户端计算这个key对应的hash slot，把请求发到slot所属的主节点即可正常执行，服务端不会做任何跨节点转发。
• 同slot多键命令：如果命令操作多个key，只要所有key计算后落在同一个hash slot上（可以通过hash tag强制控制），集群也可以正常支持。
• 不支持的命令分两类：一类是操作的多个key落在不同slot上，服务端直接返回跨slot错误；另一类是没有指定key、面向单节点全量数据的命令，比如SCAN、KEYS、FLUSHDB这类，服务端只会处理当前节点持有的数据，不会主动拉取其他节点的结果。
• hash slot的默认计算规则是对key名做CRC16运算后对16384取模，如果key包含{}包裹的片段，就只会对大括号内的内容做hash计算，这也是hash tag方案的实现原理。

MOVED/ASK重定向的实际运行逻辑 #

你对重定向机制的猜测基本正确：

• 正常情况下集群客户端会在本地缓存一份「slot-节点地址」的映射表，发请求前先算key对应的slot，直接把请求发到缓存记录的节点，不会有额外开销。
• 如果节点收到请求后发现对应的slot已经不归自己负责，会返回MOVED响应，附带正确的节点地址，客户端收到后会更新本地的映射缓存，重新连接到正确节点重试这次请求。
• 如果集群正在做slot迁移，部分数据还在源节点、部分已经迁到目标节点，源节点会返回ASK重定向，这时候客户端不会更新本地缓存，只会临时跳转到目标节点重试这一次请求，等迁移完成后就会恢复正常路由。
• 所谓重定向性能差，一般是指客户端没有做本地slot缓存、每次请求都随机发节点导致频繁重定向的场景；集群稳定运行时，重定向只会在故障转移、扩缩容的短暂时间内出现，性能损耗几乎可以忽略。

为什么客户端文档没有专门说明这些规则 #

这些逻辑不是某个客户端的专属实现，是Redis集群的通用底层运行规则，所有合规的集群客户端都遵循这套逻辑，所以客户端文档一般不会重复讲解服务端的核心机制，相关的权威说明都在Redis官方的集群规范文档里。
如果你的业务场景需要做集群全量key遍历，除了逐节点建立连接扫描、用hash tag强制key落同slot两种方案之外，生产环境更推荐的做法是单独维护key的索引，避免直接遍历Redis实例阻塞服务，影响线上请求。

内容的提问来源于stack exchange，提问作者Charlie