精通Redis 11 之 Redis cluster槽的迁移原理分析

一、槽的迁移

redis 提供redis-trlib 可以让运维手工调整槽位分配情况，
set key 的时候可以通过在key字符串里嵌入tag 标记，强制把key 所挂的槽位等于tag 所在的槽位

如图 所示，Redis 客户端向“缓存节点 1”发出请求，此时“缓存节点 1”正向“缓存节点 2”迁移数据，如果没有命中对应的 Slot，它会返回客户端一个 ASK 重定向请求并且告诉“缓存节点 2”的地址。
客户端向“缓存节点 2”发送 Asking 命令，询问需要的数据是否在“缓存节点 2”上，“缓存节点 2”接到消息以后返回数据是否存在的结果。

大致流程：

• 从源点获取内容
• 保存到目标节点
• 从源节点删除内容

详细图

注意：

redis-cluster 数据迁移是同步的，在目标节点执行restore 指令到源节点删除key 之间，源节点主线程处于阻塞状态，直达key 被成功删除。

所以操作的时候，不能在白天，选择夜深人静的时候。

如果迁移过程中遇到网络故障，整个槽的迁移进行到一半，这市两个节点依旧处于中间过渡状态，待下次迁移工具连接，会提示用户继续进行迁移。

迁移时的性能：

如果可以都很小 migrate 的指令执行的很快，不会影响正常客户端访问，如果可以的内容很大，migrate会阻塞指令，会同时导致源节点和目标节点卡顿，影响集群的稳定性，在集群状态下业务逻辑尽可能避免产生很大的key

思考：redis 支持的最大key 是

key 最大值 512m
key是按照hash查找的 ,当然越小 ,理论上越快 。 并没有必然要多长的限制 ，尽量短就可以了！
Redis key值是二进制安全的，这意味着可以用任何二进制序列作为key值，从形如”foo”的简单字符串到一个JPEG文件的内容都可以。空字符串也是有效key值。
关于key的几条规则：
太长的键值不是个好主意，例如1024字节的键值就不是个好主意，不仅因为消耗内存，而且在数据中查找这类键值的计算成本很高。
太短的键值通常也不是好主意，如果你要用”u:1000:pwd”来代替”user:1000:password”，这没有什么问题，但后者更易阅读，并且由此增加的空间消耗相对于key
object和value object本身来说很小。当然，没人阻止您一定要用更短的键值节省一丁点儿空间。
最好坚持一种模式。例如：”object-type🆔field”就是个不错的注意，像这样”user:1000:password”。我喜欢对多单词的字段名中加上一个点，就像这样：”comment🔢reply.to”。

迁移时客户端的访问流程

迁移过程中，两个节点对应的槽位都存在部分key数据，客户端首先尝试访问旧的节点，如果对应的数据还在旧节点里，旧节点正常处理。
如果不在旧节点，分两种情况 1,在新节点 2，不存在

旧节点不清楚，所以向客户端返回 -ASK targetNodeAddr重定向指令
客户单去目标节点执行一个ASKING 指令，然后再在新节点执行原先的操作指令

执行ASKING 避免形成重定向循环。
ASKING 告诉新节点，不能不理，当做自己的槽位来处理。

正常情况下:

一个指令 一个ttl

迁移情况下 三个ttl

参考书籍：《Redis 深度历险》

未经作者同意，本文禁止任何形式的转载。