redis mysql主从分离_Redis(5)-----初识Redis-----主从复制.读写分离,主从切换(哨兵机制)(示例代码)...

当数据量变得庞大的时候,读写分离还是很有必要的。同时避免一个redis服务宕机,导致应用宕机的情况,我们启用sentinel(哨兵)服务,实现主从切换的功能。

https://www.cnblogs.com/jaycekon/p/6237562.html

一,主从分离(读写分离,主从复制)

首先我们默认已经安装了redis,然后复制master,slave1,slave2三个redis的文件。并把redis.conf拷贝到多个redis文件夹中来。不干扰原来的redis服务,我们master使用6000端口

配置方式一:

配置文件(redis.conf)

master配置修改端口

port 6000requirepass123456

info命令查看

role是不是master

slave1修改配置

port 6001slaveof127.0.0.1 6000masterauth123456requirepass123456

slave2修改配置:

port 6002slaveof127.0.0.1 6000masterauth123456requirepass123456

requirepass是认证密码,应该之后要作主从切换,所以建议所有的密码都一致, masterauth是从机对主机验证时,所需的密码。(即主机的requirepass)

启动主机:

redis-server redis.conf

启动从机:

redis-server redis1.conf

redis-server redis2.conf

配置方式二:在服务启动后配置

启动6001服务

进入客户端,查看当前服务器的状态并修改:

10.192.28.149:6001> slaveof 127.0.0.1 6000

检查

输入:

ps -ef |grep redis

可以看到主从机的redis已经相应启动。

我们来验证下 主从复制。

master:

[[email protected] master]# redis-cli -p 6000

127.0.0.1:6000> auth 123456OK127.0.0.1:6000> settest chenqm

OK

slave1:

[[email protected] slave2]# redis-cli -p 6001

127.0.0.1:6001> auth 123456OK127.0.0.1:6001> gettest"chenqm"slave2:

[[email protected] slave2]# redis-cli -p 6002

127.0.0.1:6002> auth 123456OK127.0.0.1:6002> gettest"chenqm"

二,哨兵机制

2.1,哨兵机制的原理

主从复制可以把主节点的数据复制给从节点。从节点可以备份主节点的数据,起到主节点down调,顶上来接替主节点工作的作用。也可以起到分担主节点读压力的作用。

没有哨兵机制的时候,主从复制结构部署存在的问题是什么?也可以说redis主节点发生故障如何解决?

如果主节点down调,主从切换需要人工介入。

主从切换步骤为:

1、启用从节点为主节点。命令:slaveof no one

2、旧主节点的其他从节点变成新主节点的从节点。命令:slaveof new master

3、通知应用方redis主节点变成了新主节点。 修改客户端调用的地址并重启客户端。

4、旧主节点变成新主节点的从节点。 命令:slaveof new master

哨兵机制存在的意义:

为了实现redis故障转移的自动化。自动发现,自动转移。不需要人工参与。

哨兵机制是怎样的部署结构?

lazy.gif

结合上图,主从复制节点是数据节点,哨兵机制部署的节点是监控节点,它们都是redis实例。但是哨兵节点不存储数据,它们监控主从数据节点的状态,若哨兵判定主节点down掉后,就会自动执行上边提到的手工操作的4步。

哨兵节点自动化完成故障转移的过程:

lazy.gif

哨兵机制是怎样判断主节点down调的?

哨兵机制是建立了多个哨兵节点,它们共同监控数据节点的运行状况。同时哨兵节点之间也互相通信。交换对主从节点的监控状况。下面提到两个概念:

主观下线和客观下线:一个哨兵节点判定主节点down掉是主观下线。只有半数个哨兵节点都主观判定主节点down掉,此时多个哨兵节点交换主观判定结果,才会判定主节点客观下线。

基本上哪个哨兵节点最先判断出这个主节点客观下线,就会在各个哨兵节点中发起投票机制,每个哨兵都投自己为领导者。最终被投为领导者的哨兵节点完成主从自动化切换的过程。当判断为主观下线时,不会进行主从切换过程。

大家可能会好奇,如果master 重连之后,会不会抢回属于他的位置,答案是否定的,就比如你被一个小弟抢了你老大的位置,他肯给回你这个位置吗。因此当master 回来之后,他也只能当个小弟

1):每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他Sentinel实例发送一个PING命令

2):如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值,则这个实例会被 Sentinel 标记为主观下线。

3):如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4):当有足够数量的 Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态, 则Master会被标记为客观下线

5):在一般情况下, 每个 Sentinel 会以每10 秒一次的频率向它已知的所有Master,Slave发送 INFO 命令

6):当Master被 Sentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次

7):若没有足够数量的 Sentinel 同意Master 已经下线, Master 的客观下线状态就会被移除。

若 Master 重新向 Sentinel 的 PING 命令返回有效回复, Master 的主观下线状态就会被移除。

期间我们还需要关注的一个问题:sentinel服务本身也不是万能的,也会宕机,所以我们还得部署sentinel集群,象我这样多启动几个sentinel。

2.2,哨兵机制的搭建(之前看的视频说哨兵机制不需要搭建的,直接用就行了,在确认一下。)

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 1024 设计师:白松林 返回首页