REDIS CLUSTER / ROUTING LAB

一个 key,究竟该去哪个节点?

集群客户端并不是先“挑服务器”,而是先算出 0~16383 中的一个槽,再查槽位表。迁槽期间,这张表和键的真实位置会短暂错开,于是 ASK、ASKING 与 MOVED 才有了各自的意义。

bytes = UTF-8(hashKey)
crc = CRC16/XMODEM(bytes)
slot = crc mod 16384

01 / 先算槽

Hash Tag 是路由的一把“括号钥匙”

Redis 只取第一个有效的 {...}:左花括号之后必须能找到右花括号,而且中间不能为空。没有有效标签时,整个 key 参与计算。

点击结果行,可把该 key 与槽位带入下方迁槽实验。

key / 有效标签参与 CRC 的内容槽位当前节点
源节点 / Redis 红目标节点 / 青绿Hash Tag / 琥珀
节点 A0–5460
节点 B5461–10922
节点 C10923–16383
054601092216383

02 / 再迁槽

槽表没变,key 已经先走了一步

迁槽不是一次瞬移。部分 key 已经在目标节点,客户端却仍按旧槽表访问源节点。此时 ASK 是临时指路;完成迁槽后,MOVED 才是在说“更新你的地图”。

当前:槽位稳定,客户端槽表与数据位置一致。

源节点 A
槽位所有者
CLIENT →
目标节点 B
等待导入
    先点击“开始迁移这个槽”。实验会假设当前 key 已迁到目标节点,但客户端仍持有旧槽表。

    03 / 多 key 检查

    命令能不能发,不看节点名,只看是否同槽

    MGET、Lua 脚本和事务里的多个 key 必须落在同一个槽。Hash Tag 的主要价值,就是把需要一起操作的 key 明确地绑在同槽。