hash solt

Redis 在 3.0 之后，引入了 hash 槽（slot）的概念，对 redis 集群划分出 16384 个逻辑槽由所有的 master 节点持有且必须全部分配，当有 key 传入后通过 CRC-16 对传入的 key 进行 hash 处理（CRC16(key) mod 16384），将每个 key 存入对应槽中。也就是在 key -> node 中间添加了一层逻辑层，变成了 key -> slot -> node。来减弱 key 与 node 的依赖关系，也可以很好的减少迁移损耗。

• 优势：

  • 迁移时可以点对点迁移。

    例如原有 A，B 俩个节点，加入节点 C 后，可以指定将 A 中的若干个槽，转移到 C 中，迁移过程只会影响 A，C 俩个节点，而且不会影响 A 节点中其他槽内的数据。

  • 可以灵活地分配负载，通过手动指定每个节点持有的槽数，理论上可以通过持有槽的比例分配到对应比例的流量。

• 缺点：
  • master 节点数修改后，需要手动进行槽的再分配，redis 不会为新加入的节点自动分配 hash 槽。
  • 例如 Mget 之类的命令无法直接执行，除非使用 hash-tag 来显式的指定一个槽。因为并非所有 key 都可以分配到同一个 hash 槽。执行原则是：如果接受请求的节点没有持有对应槽，则转发到对应的 master 节点，始终由单一 master 节点来处理请求。

FAQ：

• 为什么 redis 要指定为 16348 个槽？

  16348 个槽，只需要占用 2kb 空间，而且 redis 的 master 节点，理论上不会超过 1000，所以 16348 完全满足对于负载均衡的支持。

参考文档

• Hash Slot vs. Consistent Hashing in Redis