SpringCloud-高级篇(十二)

SpringCloud-高级篇(十二)_第1张图片

SpringCloud-高级篇(十二)_第2张图片 

在主从集群中slave节点发生了宕机,不用担心,只要它重启就能从master节点上完成数据的同步,恢复数据,如果宕机的不是slave而是master,是不是master重启就可以呢?如果你做了master节点的数据持久化,如果你重启,数据也不会丢失,但是在master宕机这一段时间,重启数据恢复分过程当中,用户是无法执行写操作的,因为master挂了,整个集群的可用性就下降了,不能做写,只能做读了,这是我们不想看到的,我们要的是整个集群是一直可用的。

我们可以这样做要监控节点的状态,当master宕机后,重新选一个slave节点当做master,这只是一瞬间的事,这个时候整个集群一直是健康的,可以去做读操作,写操作,宕机后的原来主节点,让他当从节点就可以了

(1)Redis哨兵作用和原理

SpringCloud-高级篇(十二)_第3张图片

SpringCloud-高级篇(十二)_第4张图片

SpringCloud-高级篇(十二)_第5张图片

SpringCloud-高级篇(十二)_第6张图片

SpringCloud-高级篇(十二)_第7张图片

(2)搭建哨兵集群

SpringCloud-高级篇(十二)_第8张图片

SpringCloud-高级篇(十二)_第9张图片

SpringCloud-高级篇(十二)_第10张图片

SpringCloud-高级篇(十二)_第11张图片

SpringCloud-高级篇(十二)_第12张图片

SpringCloud-高级篇(十二)_第13张图片

SpringCloud-高级篇(十二)_第14张图片

SpringCloud-高级篇(十二)_第15张图片 

SpringCloud-高级篇(十二)_第16张图片

发现他们已经监控主节点7001 

SpringCloud-高级篇(十二)_第17张图片

我们测试让7001停止,宕机

SpringCloud-高级篇(十二)_第18张图片

从节点会发生变化:报错连接不上

Sentinel会监控做一个选举

每个Sentinel:都会监控主观下线sdowp

SpringCloud-高级篇(十二)_第19张图片

到第三个Sentinel监控的时候,已经超多两个:就会标记odown可观下线

Sentinel集群谁最先发现可观下线,会被选为主节点,进行故障恢复进行选举从节点为主节点

可以看到7002选举为了主节点,并执行了命令 不从属任何节点,写入7001配置文件更改从属关系,发送命令7003更改从属关系

SpringCloud-高级篇(十二)_第20张图片

7002此时也称为了主节点:

7003也会接收到命名执行:成为7002的从节点,从新做一次全量同步

7001重新启动看7002的日志:发现7001发现在做数据同步

(3)RedisTemplate的哨兵模式

哨兵有一个通知功能,哨兵会对集群做故障转移,master宕机,会做主从节点的切换,主从地址发生了变更,Redis客户端必须知道这些的变化,需要有哨兵通知Redis的客户端发生了故障切换,客户端可以向哨兵获取最新的地址信息

SpringCloud-高级篇(十二)_第21张图片

SpringCloud-高级篇(十二)_第22张图片

SpringCloud-高级篇(十二)_第23张图片

SpringCloud-高级篇(十二)_第24张图片

SpringCloud-高级篇(十二)_第25张图片

SpringCloud-高级篇(十二)_第26张图片

SpringCloud-高级篇(十二)_第27张图片

这里配置的不是Redis集群的地址,而是Sentinel的地址,因为在Sentinel的模式下,主从的地址是有可能变更的,不能够把它写死,而是Redis客户端不需要知道Redis集群的具体地址,只需要知道Sentinel的地址就可以了,将来基于Sentinel来做服务的地址发现

mymaste是Sentinel配置文件中maser节点的名称

 通过这些地址java客户端能够通过这些地址找到Sentinel从而得知Redis集群地址

SpringCloud-高级篇(十二)_第28张图片

SpringCloud-高级篇(十二)_第29张图片

可以在任何的配置类做这个配置,我们可以在启动类做这个配置

SpringCloud-高级篇(十二)_第30张图片

上面的匿名内部类,如果一个接口只有一个方法可以用lambda表达式来代替的

SpringCloud-高级篇(十二)_第31张图片

启动项目:SpringCloud-高级篇(十二)_第32张图片

执行读操作

SpringCloud-高级篇(十二)_第33张图片

SpringCloud-高级篇(十二)_第34张图片

SpringCloud-高级篇(十二)_第35张图片

主节点信息 :前面我们发生了主节点故障的切换

SpringCloud-高级篇(十二)_第36张图片

从节点信息 

SpringCloud-高级篇(十二)_第37张图片

建立连接:

SpringCloud-高级篇(十二)_第38张图片

上面的Get请求交给7003来查询:

SpringCloud-高级篇(十二)_第39张图片

执行写操作:

SpringCloud-高级篇(十二)_第40张图片

SpringCloud-高级篇(十二)_第41张图片

故障切换我们把7002节点弄宕机:

Sentinel发生选举:切换7001再次为主节点

7001位主节点 

7002让他恢复:从属7001

SpringCloud-高级篇(十二)_第42张图片

java客户端会重新尝试连接集群:SpringCloud-高级篇(十二)_第43张图片

得到matser是7001

SpringCloud-高级篇(十二)_第44张图片

主从切换自动完成:

从新执行get

SpringCloud-高级篇(十二)_第45张图片

找的从节点7002 

SpringCloud-高级篇(十二)_第46张图片

Set

SpringCloud-高级篇(十二)_第47张图片

找主节点7001

SpringCloud-高级篇(十二)_第48张图片

 主从自动切换,读写分离,由客户端自动实现了

你可能感兴趣的:(spring,cloud,java,spring)