Redis哈希槽和一致性哈希

前言

单点的Redis有一定的局限：

• 单点发生故障，数据丢失，影响整体服务应用
• 自身资源有限，无法承载更多资源分配
• 并发访问，给服务器主机带来压力，性能瓶颈

我们想提升系统的容量、性能和可靠性，就会将数据分散到多个节点来存储或备份，也就是集群部署。
那么，一个存储数据应该到哪个或哪些节点上来获得，应该是确定的。如果通过简单的取模算法将数据请求分散到了不同的服务器节点上，会有一个很致命的问题，如果节点数量发生了变化，也就是在对系统做扩容或者缩容时，必须迁移改变了映射关系的数据，否则会出现查询不到数据的问题。

单节点到集群

为了解决种种问题，Redis有多种集群的构建方式

• Sentinel哨兵模式：主节点支持读写，从节点支持读，哨兵阶段负责维护高可用。
  • 主节点和从节点都有全量数据，适合数据量相对较少。
  • 主节点负责写操作，主节点数据写入后将数据按照流程同步到从节点。
  • 当主节点异常后，从节点会被选举为主节点，从而完成后续的写和同步。
• Redis Cluster：一致性Hash的方案。
• Twemproxy：类似于代理模式，数据的分片和负载均衡由Twemproxy来实现。
  • TwemProxy本身不提供高可用，适用于轻量级的场景。

一致性哈希在Cluster中的作用

Cluster的需求

• 数据量大，只能存储在一个节点。
• 保证数据分布相对均匀。
• 不能影响查询效率，所有查询应该只用查询一个集群节点。
• 高可用，满足宕机恢复与扩容缩容等。

一致性哈希方案

一致性哈希算法就很好地解决了分布式系统在扩容或者缩容时，发生过多的数据迁移的问题。

一致哈希算法也用了取模运算，但与哈希算法不同的是，哈希算法是对节点的数量进行取模运算，而一致哈希算法是对 2^32 进行取模运算，是一个固定的值。

要想解决节点能在哈希环上分配不均匀的问题，就是要有大量的节点，可以加入虚拟节点，也就是对一个真实节点做多个副本。
具体做法是，不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有两层映射关系。

带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。
虚拟节点除了会提高节点的均衡度，还会提高系统的稳定性。当节点变化时，会有不同的节点共同分担系统的变化，因此稳定性更高。

一致性哈希还有一些其他的应用场景：

• RPC框架Dubbo用来选择服务提供者
• 分布式关系数据库分库分表：数据与节点的映射关系
• LVS负载均衡调度器

Redis集群分片的方案

Slot Partitioning槽分区算法

Redis集群的做法是将数据划分为 16384（2的14次方）个哈希槽（slots），如果你有多个实例节点，那么每个实例节点将管理其中一部分的槽位，槽位的信息会存储在各自所归属的节点中。
槽位的计算：

• 通常Cluster 默认基于 Key 进行 crc16 算法进行 Hash 计算，然后基于 16384 进行取模
• 特殊情况下，Cluster 可以指定某个Key挂载到特定的槽位上（通过 Tag 实现，Tag 映射槽位）
  

参考文章

面试官 ： 你能说清楚 Redis 哈希槽和一致性哈希的要点吗？
Redis系列5：深入分析Cluster 集群模式
什么是一致性哈希