Redis集群方案——Redis分片集群
前言:
我觉得无论做什么还是要知行合一,至少对于我来说只看理论是记忆不长久的,底层的细节还是无法真正体会的。前些日子也是还在焦虑实习的事情,但是也是看到了一句话:“让他们卷去吧!我躺平了,至少以后是饿不死的。”我在想确实是饿不死的,我卷也是为了以后生活质量的提高,但是无论干什么事情还是自己心里喜欢,自己愿意才能事半功倍,我喜欢坐在电脑桌前写着这些代码,与其焦虑,不如真正的放慢速度,好好的去干一些自己喜欢的事情...
于是我便想着,反正要背八股,不如真正的放慢速度,把每一章的知识重新复习一遍,其中的场景都实现一遍,每一个知识点都去做个笔记,每一个面试题都用自己的话说一遍,真正的去享受知识...
以下笔记都是基于黑马程序员的面试题写的:
Redis中关于缓存三兄弟(穿透、击穿、雪崩)和数据一致性问题的解决方案实例-CSDN博客
Redis 持久化机制_redis save 机制-CSDN博客
Redis数据过期策略_redis 如何解决数据过期-CSDN博客
Redis分片集群(Redis Cluster)是Redis官方提供的分布式解决方案,它允许数据自动分布在多个Redis节点上,提供高性能、高可用的Redis服务。
主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决:
-
海量数据存储问题
-
高并发写的问题
使用分片集群可以解决上述问题,如图:

分片集群特征:
-
集群中有多个master,每个master保存不同数据
-
每个master都可以有多个slave节点
-
master之间通过ping监测彼此健康状态
-
客户端请求可以访问集群任意节点,最终都会被转发到正确节点
1.散列插槽
Redis 分片集群引入了哈希槽的概念,Redis 集群有 16384 个哈希槽,每个 kev通过 CRC16 校验后对 16384 取模来决定放置哪个槽,集群的每个节点负责一部分 hash 槽。
1.1 插槽原理
Redis会把每一个master节点映射到0~16383共16384个插槽(hash slot)上,查看集群信息时就能看到:
数据key不是与节点绑定,而是与插槽绑定。redis会根据key的有效部分计算插槽值,分两种情况:
-
key中包含"{}",且“{}”中至少包含1个字符,“{}”中的部分是有效部分
-
key中不包含“{}”,整个key都是有效部分

那么依据以上插槽原理,如果想要进行定点存储,也就是同一种类型数据存储到相同的节点上,那么我们就可以定义{}中的有效部分是相同的。
2.集群伸缩
Redis分片集群的伸缩是指动态增加或减少集群节点的能力,包括扩容和缩容两种操作。
集群伸缩的核心机制就是哈希槽的重分配。
-
Redis Cluster将数据划分为16384个哈希槽
-
伸缩本质是重新分配这些槽位到不同节点
-
槽位迁移是原子操作,保证数据一致性
3.故障转移
Redis分片集群的故障转移是其高可用性的核心保障,能够在节点故障时自动进行主从切换,确保服务持续可用。
3.1 自动故障转移
自动故障转移就是其他的master检测不到宕机的master,确认其真的下线了,就会选取其slave为新的master,当宕机的实例恢复后会成为slave。
3.2 手动故障转移
当我们想要实现数据迁移时,可以进行手动转移操作:
利用cluster failover命令可以手动让集群中的某个master宕机,切换到执行cluster failover命令的这个slave节点,实现无感知的数据迁移。其流程如下:

这种failover命令可以指定三种模式:
-
缺省:默认的流程,如图1~6歩
-
force:省略了对offset的一致性校验
-
takeover:直接执行第5歩,忽略数据一致性、忽略master状态和其它master的意见
4.Docker搭建Redis分片集群
5.相关面试问题
5.1 redis分片集群有什么作用?
redis分片集群是redis提供的一种高并发和高可用性的分布式方案,主要解决的是海量数据存储和高并发写的场景。
首先,集群中有多个master,每个master之间通过心跳机制相互检测,类似于哨兵机制,可以进行自动故障转移,保障了服务的高可用性。
其次,每个master还可以配置多个slave,提高了服务的高并发性。
最后,客户端可以访问任意的节点,最后请求可以被转发到相应的节点访问。
5.2 redis分配集群中的数据是如何进行存储和读取的?
redis分片集群中提出了哈希槽的概念,一共有16384个哈希槽,数据不是存储到节点上的,而是存储到哈希槽中,为节点分配一定范围的哈希槽。
key通过CRC16校验,然后对16384取余来决定存储到哪个哈希槽中。
读取也是相同的逻辑。
更多推荐


所有评论(0)