实验环境（3主3从的Redis-Cluster）
一、Redis重定向基础篇
1、MOVED重定向
Redis Custer 中，客户端可以向集群中任意节点发送请求。此时当前节点先对 Key 进行 CRC 16 计算，然后按 16384 取模确定 Slot 槽。确定该 Slot 槽所对应的节点，如果该 Slot 是当前节点负责，且该 Key 存在于该 Slot 中，则直接返回该 Key 对应的结果；如果该 Slot 不是当前节点负责，则返回 MOVED 重定向告知客户端对应的节点地址信息。
2、测试
连接到redis-cluster
cd /opt
./redis-6.2.14/src/redis-cli -h 192.168.14.121 -p 18001
查询key a
192.168.14.121:18001> get a
此时MOVED重定向告诉我们key a应该去192.168.14.123节点获取
./redis-6.2.14/src/redis-cli -h 192.168.14.123 -p 18003
192.168.14.123:18003> get a
(正常获取到数据)
3、测试（自动处理MOVED重定向）
在连接Redis时加上 -c 参数
-c Enable cluster mode (follow -ASK and -MOVED redirections).
cd /opt
./redis-6.2.14/src/redis-cli -h 192.168.14.121 -p 18001 -c
###还是查询key a
192.168.14.121:18001> get a
直接帮我们重定向到key a 所在槽位的节点并返回数据。
此时可以总结出MOVED重定向的逻辑
同时还需要注意MOVED的核心原理
- Redis客户端记录的是槽与Redis服务器的对应关系，不是key与服务器的关系
二、Redis重定向进阶篇
1、ASK重定向
Ask 重定向发生于 Redis 集群进行伸缩（扩容 / 缩容）时，由于此时会进行 Slot 槽迁移。当我们去源节点访问时，数据可能已经迁移到目标节点中。故此时需要借助 Ask 重定向来解决该问题。
为什么不能继续使用MOVED重定向？
因为Redis集群中槽的迁移的时候，是槽对应的多个Key分批次进行移动，不是一次性将某个槽内的key整体迁移 ，因此迁移的槽对应的Key，存在一部分在老的服务节点，一部分在新的服务节点。
所以当访问的Key正在发生迁移时，判断其位置需要比MOVED多一次判断
彩蛋
有一种画蛇添足的路子，让Redis的客户缓存Key的位置而不是槽的位置，这样在重定向的时候性能不是大大提升了？，好像是提升了，但是Redis本身也废了。
