Redis COMMAND GETKEYSANDFLAGS 怎么检查命令键位：集群路由与访问属性预检

给 Redis 集群接入一条新命令时，最容易漏掉的不是命令本身，而是客户端到底把哪些参数当成 key。先运行 COMMAND GETKEYSANDFLAGS，让 Redis 按自己的命令解析规则返回键名和访问属性，再把结果交给路由检查；这样比在业务代码里维护一份可能过期的参数下标表可靠。

COMMAND GETKEYSANDFLAGS 适合做“命令键位预检”，但它不是跨槽执行许可。解析出 key 之后，还要继续检查这些 key 的哈希槽和目标节点。

线上报错前，先确认 Redis 认出了哪些 key

场景很具体：一个批量写入接口从 SET 扩展到 MSET，单机测试正常，切到 Redis Cluster 后却出现路由错误。代码审查时有人把第一个业务参数当成唯一 key，但 MSET 的参数是成对出现的，真正的键位需要由 Redis 的命令描述规则来判断。

先在测试实例执行：

COMMAND GETKEYSANDFLAGS MSET user:1 Alice user:2 Bob

这里传给子命令的是一条完整的 Redis 命令：MSET user:1 Alice user:2 Bob。返回数组中的键名和 key flags 才是后续检查的输入，不要把命令回显里的普通值也放进路由列表。

用 MSET 和 LMOVE 验证“键位不是固定下标”

COMMAND GETKEYSANDFLAGS 的价值在于它接收完整参数，而不是让应用猜测键的位置。对 MSET，键和值交替出现；对 LMOVE，两个列表 key 分别位于命令参数的不同位置：

COMMAND GETKEYSANDFLAGS LMOVE queue:ready queue:processing LEFT RIGHT

用 COMMAND GETKEYS 也能拿到键名，但不会附带访问 flags。需要区分哪些 key 是读入、写入，或进一步做命令权限与路由判断时，应优先使用 COMMAND GETKEYSANDFLAGS。这一步只解决“哪些参数是 key”，还没有解决“这些 key 能否在同一个集群节点执行”。

把 key positions 接到 cluster routing，而不是直接放行

预检程序可以按下面顺序处理结果：先保存 Redis 返回的 full command 对应的 key positions，再对每个 key 计算哈希槽，最后进入 cluster routing。如果两个列表 key 不在同一槽，客户端仍然要返回跨槽风险；如果业务允许调整命名，可以给相关 key 使用相同的 hash tag，例如 {job}:ready 和 {job}:processing。

完整命令
  -> COMMAND GETKEYSANDFLAGS
  -> key positions
  -> cluster routing
  -> 同槽放行 / 跨槽拒绝

这里不要把“能解析出 key”误读成“命令一定能执行”。Redis 官方文档把命令解析和集群执行分成两个层次；尤其是多 key 命令，最终是否可执行还取决于 key 的槽位关系以及客户端对 MOVED、ASK 等响应的处理。

把命令预检放在哪个位置更稳

高频路径不必每次业务请求都调用慢命令类别的元命令。更合适的做法是在命令模板变更、客户端启动自检、灰度发布和异常命令采样时调用；生产执行仍由客户端正常发送业务命令，并记录真正的路由结果。官方资料给出的复杂度是 O(N)，N 是命令参数数量，参数很多的批量命令也应设置采样或长度上限。

常见问题：把键位预检接到集群路由

为什么 COMMAND GETKEYS 和 COMMAND GETKEYSANDFLAGS 不能完全互换？

两者都能从完整命令中找 key，但后者额外返回每个 key 的访问 flags。只做键名提取时前者够用；需要把读写属性带入检查时，使用后者信息更完整。

返回了两个 key，是否代表 LMOVE 一定可以执行？

不是。两个 key 还要经过 hash slot 检查；不在同一槽时，集群命令仍可能失败。hash tag 只能在业务允许改变 key 命名时使用，不能临时掩盖数据分布问题。

为什么不在应用里写死 MSET 的参数下标？

固定下标很容易在新增命令、模块命令或参数结构变化时失效。让 Redis 命令解析器返回 key positions，应用再做槽位和节点判断，职责边界更清楚。

验证结果：把它当作路由前的证据，不是放行开关

这条排查链最终留下三份证据：Redis 对完整命令识别出的 key、每个 key 的访问 flags，以及集群计算出的槽位和目标节点。三份结果一致，才可以把命令送入灰度；只拿到第一份结果时，最多说明参数解析正确。

如果线上仍出现跨槽或 MOVED，优先对照实际发送的完整命令和预检记录，确认中间是否改写了 key、追加了参数，或者使用了与测试环境不同的模块命令版本。这样查问题，比继续扩大客户端里的特殊分支更容易回滚。