2021-04-01-一致性哈希与哈希槽

个人博客地址：http://radarsoftware.cn/

前言

随着缓存技术出现，分布式存储的缓存集群无疑极大的提升了数据访问速度。但缓存该按照什么规定去存储到指定的节点(集群中的某个缓存服务器),新增或删除某几台缓存服务器后对以前的缓存的查找怎么办，如何处理。以下以redis非关系型内存数据库为例。

缓存集群分配节点问题

一台或多台应用服务器的数据放入多台redis缓存服务器中时如何选择存到哪台缓存服务器，如何让数据尽可能均衡的存储数据做到负载均衡？

新增删除缓存服务器影响缓存查找问题

如果现有的缓存服务器容量不够，新增缓存服务器如何较低风险的处理应用服务器对以前缓存数据的查找，避免新增缓存服务器时查找以前缓存服务器地址出错。

解决方案

余数算法

提到分配自然而然地想到可以通过对要存储的key(redis K-V)值 hash后对服务器数量求余数，然后根据余数分配到指定缓存服务器。如下图：

问题：如何保证缓存的负载均衡？新增后余数算法得到的缓存服务器地址结果和以前不一致导致的大量缓存失效问题进而带来的缓存雪崩问题。如下图：

一致性哈希

采用一致性哈希可以避免大量的缓存失效，将hash空间想象成一个圆，用各服务器的IP或者hostname进行hash算法求hashcode(在2^32之内，java hashcode为int类型32位，4个字节)，对于要缓存的数据或要查找的数据再根据对key的hash值顺时针找到的第一台服务器位缓存服务器。如下图:

新增服务器时，可以发现影响的缓存只有新增的服务器到新增服务器逆时针最近一台服务器之间的缓存受到影响，，不会导致大面积缓存失效。

一致性hash实习负载均衡，通过将一台缓存服务器看作多台缓存服务器进行hash后映射到hash空间圆圈上

哈希槽

Redis Cluster(集群)在设计中没有使用一致性哈希（Consistency Hashing），而是使用数据分片引入哈希槽（hash slot）来实现一个 Redis Cluster包含16384（0~16383）个哈希槽，存储在Redis Cluster中的所有键都会被映射到这些slot中，集群中的每个键都属于这16384个哈希槽中的一个，集群使用公式slot=CRC16（key）/16384来计算key属于哪个槽，其中CRC16(key)算法语句用于计算key的CRC16 校验和。
按照槽来进行分片，通过为每个节点指派不同数量的槽，可以控制不同节点负责的数据量和请求数

新增服务器hash槽重新分配

哈希槽补充：

哈希槽为什么是16384（2^14）个？
在redis节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，16384=16k，在发送心跳包时使用char进行bitmap压缩后是2k（2 * 8 (8 bit) * 1024(1k) = 16K），也就是说使用2k的空间创建了16k的槽数。

虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，65535=65k，压缩后就是8k（8 * 8 (8 bit) * 1024(1k) =65K），也就是说需要需要8k的心跳包，作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。