上一篇文章中,我们介绍了 redis 集群的搭建。 redis 集群详解及搭建过程 其中我们遇到了报错:
这就是所谓的“MOVED转向”,那么什么是 MOVED 转向呢?本篇日志我们就来介绍一下。
当我们使用操作 redis 单节点的 client 来操作集群时,常常能够遇到上面的报错。 按照 redis 官方规范,一个 Redis 客户端可以向集群中的任意节点(包括从节点)发送命令请求。 节点会对命令请求进行分析,如果该命令是集群可以执行的命令,那么节点会查找这个命令所要处理的键所在的槽。 如果处理该命令的槽位于当前节点,那么命令可以顺利执行,否则当前节点会返回 MOVED 错误,让客户端到另一个节点执行该命令。 redis 官方规范要求所有客户端都应处理 MOVED 错误,从而实现对用户的透明。 我们上面看到的错误就是 MOVED 错误:
(error) MOVED 866 172.21.16.4:6379
他表示,该执行该命令所需要的 slot 是 866 号哈希槽,负责该槽的节点是 172.21.16.4:6379。
每次 REDIS 指令操作后,客户端应该记录下正确的节点与槽之间的对应关系 — 槽位路由表。 这样在下次指令执行时可以找到正确的节点,从而提升效率。
Redis 的规范体现出了 Redis 的哲学 — 保持 server 端的尽量简洁,能不在 server 端做的事情都不在 server 端做。 这已经是我们不止一次提到的原则了。
ASK 转向是在集群在线重配置发生时出现的一种错误返回。 所谓的集群在线重配置就是 slot 的迁移,下面是用于 slot 迁移的命令:
前面的命令很好理解,只有最后的两条命令需要详细解释: 假设我们在 A 节点执行:
CLUSTER SETSLOT 866 MIGRATING B
同时,我们在 B 节点执行:
CLUSTER SETSLOT 866 IMPORTING A
这样,我们将 866 号槽从 A 节点迁移到 B 节点。 这样,再次请求 866 槽时,都会判断操作的键是否是一个新的键,如果是一个新的键,那么就在 B 节点中进行操作,否则仍然在 A 节点中进行操作。 对于试图在 A 节点中 866 槽上新增键的操作,A 节点会返回一个 ASK 转向错误,指向 B 节点。 也就是说,MIGRATING、IMPORTING 命令不会进行数据的迁移,只决定新数据的去向。 而在这一组操作进行中,这两个节点都会被阻塞,以免竞争条件的发生。
除了 MOVED 转向,Redis 规范还要求客户端实现对 ASK 转向的处理。 MOVED 转向与 ASK 转向的区别类似于 http 协议中 301 跳转与 302 跳转的区别:
客户端是不能直接请求 ASK 转向的目标机器的,而是必须先发送一个 ASKING 命令。 因此,客户端也没有必要了解或保存槽位与节点的对应关系。
https://redis.io/topics/cluster-spec。 https://redis.io/commands/cluster-setslot。 https://github.com/go-redis/redis/blob/master/cluster.go。