Redis哈希槽和一致性哈希

前言

单点的Redis有一定的局限：

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

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

单节点到集群

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

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

一致性哈希在Cluster中的作用

Cluster的需求

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

一致性哈希方案

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

一致哈希算法也用了取模运算，但与哈希算法不同的是，哈希算法是对节点的数量进行取模运算，而一致哈希算法是对 2^32 进行取模运算，是一个固定的值。
在这里插入图片描述
要想解决节点能在哈希环上分配不均匀的问题，就是要有大量的节点，可以加入虚拟节点，也就是对一个真实节点做多个副本。
具体做法是，不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有两层映射关系。
在这里插入图片描述
带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。
虚拟节点除了会提高节点的均衡度，还会提高系统的稳定性。当节点变化时，会有不同的节点共同分担系统的变化，因此稳定性更高。