背景
关于 Redis Cluster 中的重定向问题，网上有很多大佬都已经说明了存在Moved/Ask两种重定向标识，也解释了其中Moved/Ask两种重定向标识的区别，这里也不再重复解释说明。这里重点想说明一点看这些文章对于我来说有个美中不足的点：都没有解释说明为什么需要两种Moved/Ask两种重定向标识，我用一种标识能不能实现呢？ 特此记录一下这个对于我来说的一个灵魂问题，不知道大家会不会有这个疑惑，欢迎交流😆😆😆
为什么需要两种Moved/Ask两种重定向标识，我用一种标识能不能实现呢?
首先明确三个核心信息：
- Redis客户端记录的是槽与Redis服务器的对应关系，不是记录Key与服务器的关系，
- 一个槽对应多个Key
- Redis访问的时候基于Key，计算出来对应槽，然后基于槽找到对应的Redis服务器 其次明确核心场景&解决思路：
- Redis集群中槽的迁移的时候，是槽对应的多个Key分批次进行移动，不是All in的，因此迁移的槽对应的Key，存在一部分在老的服务节点，一部分在新的服务节点。 对于核心场景中出现的情况，如何解决呢？
| 解决方案 | 优点 | 缺点 | 备注 |
|---|---|---|---|
| 客户端缓存槽与Redis服务器映射，通过Moved/Ask两种重定向标识 | 客户端不需要缓存Key与服务器映射关系，缓存容量可控(槽与服务映射关系) | 迁移过程中，对于迁移槽的Key的访问都存在两次网络请求，导致性能变差，槽迁移完成之后，可更新槽与服务器关系然后性能重新回到最优 | 核心点：时间换空间 |
| 客户端缓存Key与Redis服务器映射，通过一种重定向标识 | 仅迁移后的第一次访问存在两次网络请求，后面都是一次，性能好 | 按照Key的维度会占用很多空间，最主要是不能预估每个Redis Cli 端的容量 | 核心点：空间换时间 |
最后明确结论&个人思考：
- 通过上述方案对比，其实我们是可以基于一种标识实现，尽管代价看起来有点高，而且不可控,不太可取。
- 虽然上面说的基于Key与服务器映射关系代价高于收益，但是这个是基于一个前提条件：为了通用性，进行全量缓存，但是如果我们不是全量缓存呢？比如对于迁移槽中的热点Key实施Key与与服务器映射，这样就可以进行迁移过程中Redis访问优化，其实对于Jedis这种客户端是否可以修改源码进行相关定制化优化来做到这一点。
