赞
踩
我们日常不使用docker来部署redis集群,基本上都是直接使用redis启动,是在redis的文件里面进行
但是,如果像在任意位置能执行redis-server的话,需要配置环境变量。
回归正题,我们需要搭建一个集群,我们先在虚拟机上面进行。
这个前提里面我们已经把redis.conf复制了三份数据分别放在7001,7002,7003里面去.
首先我们在虚拟机上三个redis的开启。分别对应的端口号为7001,7002,7003。
其次,我们需要在redis.conf文件里面添加replica-announce-ip参数.作用其实就是为了确保在这些redis从节点能在集群里面进行发布自己的ip地址.
直接添加第一行数据。
此时这里已经对redis的集群基本配置已经配置完毕,我们来尝试一下连接!
发现连接不上!
第一种情况:虚拟机的防火墙没有关闭。
第二种情况:bind没有进行注释掉,并且还没有关闭保护模式。(原来是因为配置文件中的bind没有进行注释。其实bind指向127.0.0.1其实也就是只允许虚拟机本机通过回环地址来连接redis。我们来进行修改。)
然后就可以正常连接上了。
在配置文件里面添加一行配置 slaveof <masterip><masterport>.在这样就去确定当前redis的主是那一个。这里填上ip地址,以及端口。
在redis服务里面执行 slaveof <masterip><masterport>.命令。
验证是否已经建立好主从关系。直接在主的服务里面执行info replication来查看
而主从关系我们看这样图:
我们可以清晰的了解到,redis集群默认是主节点读写都可以的操作,从节点只做读的操作。
那主从数据如何进行同步的咧?
分两种情况:
主要发生在第一次连接的时候,执行全量同步把master的所有数据拷贝给slave节点。
简称:replid,数据集的标记,每一个master都有一个唯一的replid(并且slave本质上也是一个master,也会有自己的replid),当slave连接上后,master会发现slave的replid与其不相同,所以就判断为是第一次同步,就会做全量同步。之后slave就会继承master的id值。
通过replid我们可以判断得出是否进行全量同步,那增量同步就通过repl_backlog来进行的。
offset :
偏移量,随着记录命令日志增多而逐渐增大。其实我可以理解为就是做数据的记录备份。
repl_backlog:
偏移固定大少的环型数组,也就是角标达到数组末尾,这个数据就会进行数据覆盖。
这个环里面记录的数据有命令日志数据,以及对应的偏移量。
当出项slave出现了网络阻塞时,master的命令日志数据以及偏移量远远超过slave时。
此时被框选的部分的slave未同步的偏移量就会被更新掉,然后slave就会发现自己的offset没有了。无法完成增量同步,就到最后只能进行全量同步了。
哨兵作用:
监控:sentinel会不断的检查redis的主从节点是否正常运作。
自动故障恢复:也就是当redis的主节点故障之后,会迅速安排一个从节点接上。
通知:也就是告诉redis从节点,主节点故障了。
监控的原理:类似微服务一样,基于心跳机制来进行监控,sentinel每一秒会对所有节点进行一个ping命令来确保节点是否存货
(1)主观下线:也就是某个sentinel在1s里面发送的ping没有在规定时间内响应,就为主观下线。
(2)客观下线:主要用于集群,也就是集群里面当quorum个sentinel都认为该主节点没有响应,就为客观下线。
其实也就是结合微服务里面的sentinel来对redis进行一个集群管控操作。首先sentinel我们都知道使用来做微服务保护的。来对微服务进行限流访问以及熔断机制的。
但是我们回想一个点,假设单节点的sentinel挂掉之后,对一个的sentinel对微服务的保护机制就没有了。所以我们要搭建sentinel的时候需要进行集群搭建。当然单节点的sentinel也可以,但是不安全!
并且!!!redis里面是有sentinel的!也就是内置了sentinel!所以我们是不需要在外置开启sentinel的。只需要使用redis-sentinel命令就可调用redis里面的sentinel!
注意的是:redis集群一定要一直开着。这个redis-sentinel是用来监控redis的。
我们只需要写好sentinel配置文件即可:
然后通过使用命令来根据每个配置文件来以哨兵模式来启动。
假设我们把7001的redis给宕机了,看一下27001也就是sentinel的日志信息。
此时对应的7003与7002也有有日子信息的导入。
在spring中如何配置根据哨兵机制来进行读写分离咧?
我们都知道spring-redis提供了一个redisTemplate的封装类。我们只需要调整application.yml文件里面redis的连接端口就可以使用redisTemplate来发送数据到redis里面去。如果要做读写分离的话,我们此时在application.yml文件里面配置上这样:
而RedisTemplate的底层是利用lettuce实现了节点的感知和自动切换。
此时如果我们需要对其进行读写分离的话,就需要重写lettuce类,并且把其放入到spring容器里面去。
主从结构是为了进行读写分离,而哨兵机制,是为了在主从结构的基础上预防主节点丢失的一个保护机制。而这两个围绕着都是一个主节点(master),多个从节点(slave)
那如果当有大量的数据要进行写入,单个master是无法支持得到,所以对数据进行一个分类!把不同的数据分到不同的master上面进行管理,此时就需要使用到分片集群。
(通俗易懂来说,就是要有多个主节点,实现数据分区。)
首先,开启集群的前提那肯定是开启redis,而开启集群的话,只需要在redis的配置文件上,添加开启集群功能,以及进群的心跳检查。
用对应的配置文件进行开启。因为daemonize为yes,也就是后台运行,此时我们想知道redis是否全部开启。使用查看进程命令。
注意:现在只是开启了redis服务,并没有形成分片集群,要形成分片集群,就需要进行一下操作。
我们使用的redis是6.2.6版本的redis,对应redis5.0之后,集群管理已经集成到了redis-cli命令里面去了。
--cluster:代表使用集群操作命令。
create:创建集群。
--replicas 1:也就是设置replicas=1提供的端口的节点总数的基础上/(replicas+1),此时有6的接口,除以2对应就是有3个主节点。
我们可以通过这个图,可以看到slots就是redis把主节点分配的插槽位置。
redis-cli -p 集群任意端口 cluster nodes
此时如果要在redis里面存放数据的时候,之前是通过redis-cli -p 端口。然后直接把set放入进去。
当时因为现在是以集群形式。所以对应的数据会分区来进行输入。redis会通过存入的数据进行一个转化,转化为插槽对应的数值。
所以我们之后要通过redis-cli -p -c 端口,来进入redis服务。
redis会根据key的CRC16算法得出一个哈希值,然后对16384进行取余,这样的话就会得到slot也就是插槽值。但是需要留意一个点。
也就是key={itcast}num的时候计算的就是{}里面的itcast的哈希值。
假设中途需要添加新的节点到集群里面:
(1)先启动节点(根据集群部署的配置文件来进行部署)
开启:
(2)使用redis-cli 里面的命令 --cluster 的添加节点的命令(add-node)
此时我们在查看一下对应集群里面的信息。cluster nodes
7004的插槽范围是为0!所以此时7004是无法用来存储信息的!
(1).通过命令redis-cli的--cluster 里面的reshard 端口。这里的重点是找到当前端口对应的集群。而并不是对某个节点进行插槽拆分。reshard
(2)确定这3000个插槽是给那个节点使用的。
(3)决定用什么方式来抽取这3000个插槽出来:
我们现在来看一下转移后对应的插槽范围值:
我们用的方法是all,所以此时会发现,插槽分了三个部分。分别都是原本7001,7002,7003里面的插槽!
我们现在需要假设一个点:也就是我们之前都是通过哨兵机制来进行主节点故障之后,让从节点代替的,那分片集群式假设也出现这种情况的时候,那分片集群式如何解决的咧?
也就是分片集群会自动进行主节点的替换。当我们把7002的进程杀掉后,也就是让7002这个redis服务宕机!
假设,我现在7002的端口又重新启动的。但是我又想让其变会主节点。此时就需要进行手动调试。
工作原理就是进入7002服务器里面,执行cluster failover(故障转移)命令。
此时7002就恢复主节点,8002就恢复为从节点!
而spring-redis如何进行分片集群整合,与哨兵机制一样。
(1)注入spring-redis的依赖
(2)编写读写分离策略的bean!(一模一样的)
(3)application.yml文件的编写(差异点)
课外拓展:
我们可以使用docker来部署redis,重点来了,如果我们没有给其设置配置文件,会按redis内部里面执行配置文件,以6379为端口,无法去修改,这个与mysql不同,mysql是可以去对默认的配置文件进行替换的。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。