大厂面试官问我：Redis为什么使用哈希槽的方式进行数据分片？为什么不适用一致性哈希的方式？【后端八股文十三：Redis 集群哈希八股文合集（1）】
本文为【Redis 集群哈希 八股文合集（1）】初版，后续还会进行优化更新，欢迎大家关注交流~
hello hello~ ，这里是绝命Coding——老白~💖💖 ，欢迎大家点赞🥳🥳关注💥💥收藏🌹🌹🌹
💥个人主页：绝命Coding-CSDN博客
💥 所属专栏：后端技术分享
这里将会不定期更新有关后端、前端的内容，希望大家多多点赞关注收藏💖
往期内容（篇幅过多，不一一列出，感兴趣的小伙伴可以查看专栏）：
大厂面试官问我：Redis处理点赞，如果瞬时涌入大量用户点赞（千万级），应当如何进行处理？【后端八股文一：Redis点赞八股文合集】-CSDN博客
大厂面试官问我：布隆过滤器有不能扩容和删除的缺陷，有没有可以替代的数据结构呢？【后端八股文二：布隆过滤器八股文合集】-CSDN博客
redis做集群时如何高效快速找到对应的节点 / Redis Cluster 如何分配命令在哪个节点上执行
哈希槽
原因：
- 简单高效:哈希槽是一个 0-16383 的整数范围,通过对 key 进行 CRC16 计算后对 16384 取模就可以确定该 key 属于哪个槽。这种方式计算简单高效,且容易管理和维护。
- 负载均衡:Redis 集群会尽量将 16384 个槽均匀地分配到各个节点上,从而达到良好的负载均衡效果。当集群节点数发生变化时,只需要在节点间进行槽的迁移,不需要重新计算每个 key 的路由。
- 扩展性:当集群需要扩展时,可以将部分槽迁移到新加入的节点上,无需对所有 key 进行rehash。这种方式可以平滑地扩展集群规模。
Redis为什么使用哈希槽的方式进行数据分片？为什么不适用一致性哈希的方式？/ redis的hash slot算法，与哈希环算法区别
Redis 选择使用哈希槽（hash slot）是因为它更加简单高效:
- 哈希槽是一个 0-16383 的整数范围,通过对 key 进行 CRC16 计算后对 16384 取模就可以确定该 key 属于哪个槽。这种方式计算简单高效。
- 相比之下,一致性哈希需要维护复杂的哈希环拓扑,扩展时需要重新计算所有 key 的路由,不够灵活。
- 哈希槽可以将 16384 个槽均匀地分配到各个节点上,从而达到良好的负载均衡效果。当集群节点数发生变化时,只需要在节点间进行槽的迁移,不需要重新计算每个 key 的路由。
了解redis的哈希环吗？如何做到哈希一致性？
哈希环(Consistent Hashing):
Redis使用哈希环(Consistent Hashing)算法来实现哈希一致性。这个算法的核心思想是:
- 将所有的节点和key都映射到同一个哈希空间(如0-2^32-1)的圆环上。
- 增加或删除节点时,只影响相邻的节点,其他节点基本不受影响。
- 这样可以很好地解决增加/删除节点时数据迁移的问题,提高了系统的伸缩性。
什么是哈希环
如上图
- 我们有一个虚拟的哈希环,将节点 (Node 1、Node 2、Node 3) 和数据项 (Key 1) 都映射到这个环上。
- 当我们需要存储一个数据项时,我们会根据该数据项的 hash 值将其定位到哈希环上的某个位置,并将其存储到顺时针方向第一个遇到的节点上
- 比如 Key 1 被定位到 Node3 上
- 当我们新增或删除节点时,只需要调整少量数据项的存储位置,而不需要大规模的数据迁移。
- 比如如果我们新增了 Node 4,那么 Key 3 可能会被重新分配到 Node 4 上,但其他 Key 的存储位置不会受到影响。
具体新增：
比如:
（
-
有三个节点:
- Node 1 位于左上方,占据了大约1/4的环空间。
- Node 2 位于右上方,占据了大约1/4的环空间。
- Node 3 位于中心,占据了剩余的1/2环空间。
-
有两个数据项:
- Key 1 位于左上方,接近Node 1。
- Key 2 位于右下方,接近Node 2。
）
- 有两个节点 Node 1 和 Node 2,分别存储了 Key 1 和 Key 2。（根据一致性哈希算法：Key 1 被存储在顺时针方向第一个遇到的节点Node 1上，key 2 被存储在顺时针方向第一个遇到的节点Node 2上）
- 现在我们新增了一个节点 Node 3。
- 为了将 Node 3 加入到哈希环中,我们需要重新计算哈希环上的数据分布。
- 按照一致性哈希算法的规则,Key 1 仍然存储在 Node 1 上,因为它距离 Node 1 最近。
- 但 Key 2 原本存储在 Node 2 上,现在需要被重新分配。根据一致性哈希算法,Key 2 应该被存储在顺时针方向第一个遇到的节点 Node 3 上。
- 所以经过这次节点变更,只有 Key 2 需要被迁移到新的节点 Node 3 上,而 Key 1 的存储位置保持不变。这就大大减少了数据重分布的开销。
Redis 哈希槽的概念？
Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念， Redis 集群有16384 个哈希槽，每个key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽， 集群的每个节点负责一部分 hash 槽。
哈希槽是如何映射到 Redis 实例上的？/ 哈希槽在redis中是如何存储的
节点取余分区。使用特定的数据，如Redis的键或用户ID，对节点数量N取余：hash（key）%N计算出哈希值，用来决定数据映射到哪一个节点上。
虚拟槽分区，所有的键根据哈希函数映射到0~16383整数槽内，计算公式：slot=CRC16（key）&16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。**Redis Cluser采用虚拟槽分区算法。
redis哈希槽为什么16384
16384 这个数字是经过权衡后选择的:
- 16384 是 2^14,是一个比较大的素数,可以较为均匀地分配给集群节点。
- 16384 个槽够用于大多数应用场景,既不会过于浪费内存,也不会造成过多的槽迁移开销。
- 使用 16 位 CRC16 哈希函数可以快速计算出 key 所属的槽号,计算效率高。
Redis一致性哈希是如何用的？怎么判断slot是属于哪个节点。初始化的时候怎么分配的slot的？
一致性哈希的使用:
- Redis 使用一致性哈希算法将所有节点和 key 映射到同一个哈希环上。
- 当客户端需要查找某个 key 时,会通过哈希函数将该 key 映射到哈希环上的一个点。
- 然后顺时针查找最近的节点,即可找到负责该 key 的节点。
如何判断 slot 属于哪个节点:
- Redis 将哈希空间分成 16384 个固定大小的槽位(slot)。
- 每个 key 根据其 key 值经过 CRC16 哈希函数计算,得到一个 0-16383 之间的整数值,这个值就是该 key 所在的槽位。
- 每个 Redis 节点负责管理一部分连续的槽位。通过维护一个槽位与节点的映射关系,就可以确定某个槽位属于哪个节点。
初始化时的槽位分配:
- 在 Redis 集群初始化时,会将 16384 个槽位平均分配给集群中的所有节点。
- 例如,如果集群有 3 个节点,那么每个节点会被分配 0-5460、5461-10920 和 10921-16383 三个槽位区间。
- 当添加或删除节点时,Redis 会根据新的节点数重新计算每个节点应该负责的槽位区间,并自动进行槽位的迁移。
redis集群新增一个节点和删除一个节点后如何解决雪崩现象？
环哈希
为什么使用一致性哈希?
- 传统哈希算法(如取模)在节点变更时,会导致大量 key 的重新分布,引发大量的数据迁移和客户端路由更新,容易造成雪崩效应。
- 而一致性哈希算法通过将节点和 key 都映射到一个虚拟的哈希环上,在节点变更时只需要调整少量 key 的映射关系,减少了数据迁移和客户端路由的开销。
cluster 在服务器扩容时如何 rehash，哈希槽如何计算
当增加或减少 Redis 集群的节点时,需要对哈希槽进行重新分配,这个过程称为 rehash。
rehash 的具体步骤是:
计算新的哈希槽分配方案
迁移数据到新的槽位
更新客户端路由信息
哈希槽的计算公式是: slot = crc16(key) & 16383
crc16 是一种常用的哈希算法
结果被 16383 取模,得到 0-16383 之间的槽位号
多个主库如何实现
在 Redis 中,一般不会存在多个主库的情况,因为这样会导致数据一致性问题。
如果确实有这种需求,可以考虑使用 Redis 集群模式,通过哈希槽的方式将数据分散在多个主节点上。
后期新的八股文合集文章会继续分享，感兴趣的小伙伴可以点个关注~
更多精彩内容以及免费资料请关注公众号：绝命Coding
