Redis集群

皮克斯的进化之路

于 2024-10-02 00:44:34 发布

阅读量1k

点赞数 37

分类专栏： Redis 文章标签： redis 数据库 mysql

本文链接：https://blog.csdn.net/m0_74166099/article/details/142676147

版权

8 篇文章 0 订阅

订阅专栏

集群概念

上一篇我们讲到了哨兵模式，提高了系统的可用性，但是真正用来存储数据的还是master跟slave节点，所有的数据都需要存储在单个的master和slave节点中。

如果数据量很大，超出了节点所在机器的物理内存，就会出现严重问题了。

那如何获得更大的空间呢，加机器就可以，一台机器搞不定，就用多台机器。

Redis集群就是在上述的思路下，引入多组的master跟slave，每组的master跟slave存储数据全集的一部分，从而构成一个更大的集体，称为Redis集群。

假设整个数据全集是1TB，此时引入三组master跟slave，则每组机器只需存储整个数据全集的1/3即可，每个红框部分可以称为一个分片，如果全量数据进一步增加，只要再增加更多的分片就行。

Redis集群的核心思路就是用多组机器来存数据的每个部分，那么就有一个核心问题：给定一个具体的key，那么整个数据应该存储到哪个分片上？读取的时候又应该去哪个分片读取呢？

针对这个问题，目前有三个比较主流的实现方式：

设由N个分片，用【0，N-1】的顺序编号；

针对某个给定的key，先计算hash值，再把得到的结果%N，得到的结果就是分片编号。

如上图所示。

此分片算法的优点：简单搞笑，数据分配均匀。缺点：一旦需要扩容，N改变了，原有的映射规矩就被破坏，就需要让节点之间的数据相互传输重新排序，则此时需要搬运的数据量事比较多的，开销较大。

为了降低上述的搬运开销，能够更高效的扩容，所以提出了“一致性哈希算法”。

这就相当于n个分片位置把整个圆环分成了n个管辖区间，key的hash值落入某个区间就归对应区间管理。

此时如果扩容一个分片，就只需原有分片在环上的位置不懂，在环上安排一个新分片即可~

此时只需要把0号分片上的部分数据搬运给3号分片上即可，1号分片和2号分片的管理区间不变。

优点：大大降低了扩容时数据搬运的规模，提高了扩容操作的效率。

缺点：数据分配不均。

为了解决上述问题，redis集群引入了哈希槽算法。

hash_slot = crc16(key) % 16384（其中crc16也是一种hash算法）

相当于把整个哈希值映射到16384个槽位上，然后再把这些槽位比较均匀的分配给每个分片，每个分片的节点都需要记录自己持有哪些分片。

如果需要扩容，就可以把之前每个分片持有的槽位各拿出一点，分给新分片。

还有两个问题：

1.redis集群是最多有16384个分片吗？

并⾮如此. 如果⼀个分⽚只有⼀个槽位, 这对于集群的数据均匀其实是难以保证的.

实际上 Redis 的作者建议集群分⽚数不应该超过 1000。

2.为什么是16384个槽位？

节点之间通过⼼跳包通信. ⼼跳包中包含了该节点持有哪些 slots. 这个是使⽤位图这样的数据结构表⽰的. 表⽰ 16384 (16k) 个 slots, 需要的位图⼤⼩是 2KB. 如果给定的 slots 数更多了, ⽐如 65536 个了, 此时就需要消耗更多的空间, 8 KB 位图表⽰了. 8 KB, 对于内存来说不算什么, 但是在频繁的⽹络⼼跳包中, 还是⼀个不⼩的开销的。
另⼀⽅⾯, Redis 集群⼀般不建议超过 1000 个分⽚. 所以 16k 对于最⼤ 1000 个分⽚来说是⾜够⽤的, 同时也会使对应的槽位配置位图体积不⾄于很⼤。