Redis-5.0.3主从复制和哨兵

最新推荐文章于 2019-08-16 15:35:17 发布

运维求知者

最新推荐文章于 2019-08-16 15:35:17 发布

阅读量167

点赞数

本文链接：https://blog.csdn.net/weixin_43407305/article/details/88557638

版权

一.Redis主从复制原理和配置

1.和MySQL主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。
2. Redis主从拓扑
a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响

在这里插入图片描述
b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。
在这里插入图片描述
1 全量同步
　　Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：
　　1）从服务器连接主服务器，发送SYNC命令；
　　2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
　　3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
　　4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
　　5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
　　6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
　　在这里插入图片描述
完成上面几个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求。
2 增量同步
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
3 Redis主从同步策略　　　　　　
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，加粗样式首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
4 注意点
如果多个Slave断线了，需要重启的时候，因为只要Slave启动，就会发送sync请求和主机全量同步，当多个同时出现的时候，可能会导致Master IO剧增宕机。

实验环境：

主机	ip
server1（redis-master）	172.25.5.1
server2（redis-slave）	172.25.5.2
server3(redis-slave)	172.25.5.3

1.准备安装包
redis-5.0.3.tar.gz
2.安装：
server1（master），server2（slave），server3（slave）redis的安装一致，以server1为例

[root@server1 ~]# ls
redis-5.0.3.tar.gz
[root@server1 ~]# tar zxf redis-5.0.3.tar.gz 
[root@server1 ~]# cd redis-5.0.3
[root@server1 redis-5.0.3]# yum insatall gcc -y ##安装gcc依赖包
[root@server1 redis-5.0.3]# make && make install  ##安装下载
[root@server1 redis-5.0.3]# cd utils/
[root@server1 utils]# ./install_server.sh  ##执行redis的安装脚本

在这里插入图片描述
3.配置
server1（redis-master）:
编辑redis的配置文件

[root@server1 utils]# vim /etc/redis/6379.conf 
70 bind 0.0.0.0

在配置文件redis.conf中，默认的bind 接口是127.0.0.1，也就是本地回环地址。这样的话，访问redis服务只能通过本机的客户端连接，而无法通过远程连接，这样可以避免将redis服务暴露于危险的网络环境中，防止一些不安全的人随随便便通过远程连接到redis服务。如果将bind选项注释的话，那会接受所有来自于可用网络接口的连接。此处为了实验

server2,server3（redis-slave）:

[root@server2 utils]# vim /etc/redis/6379.conf 
70 bind 0.0.0.0
282 slaveof 172.25.19.1 6379   ##添加salve指向master为server1
[root@server3 utils]# vim /etc/redis/6379.conf 
70 #bind 0.0.0.0
282 slaveof 172.25.19.1 6379

3.启动redis服务

[root@server1 utils]# /etc/init.d/redis_6379 start
[root@server2 utils]# /etc/init.d/redis_6379 start
[root@server2 utils]# /etc/init.d/redis_6379 start

4.测试
1.查看各个节点的服务状态
server1（master）：
在这里插入图片描述

server2（slave）：

server3（slave）：

2.主从测试
1.在server1上写入key-vlave

2.在server2，server3上可以看到数据同步过来了

二、Redis哨兵机制（Sentinel）

为什么要有哨兵机制？

哨兵机制的出现是为了解决主从复制的缺点的
哨兵机制(sentinel)的高可用

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
在这里插入图片描述
其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知
3. 哨兵的定时监控任务
任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
在这里插入图片描述
任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的
在这里插入图片描述
任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线
在这里插入图片描述
4. 领导者哨兵选举流程

a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举
在这里插入图片描述
5. 故障转移机制
a)由Sentinel节点定期监控发现主节点是否出现了故障
sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
在这里插入图片描述
b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行

流程：

1. 将slave-1脱离原从节点，升级主节点，

     2. 将从节点slave-2指向新的主节点

     3. 通知客户端主节点已更换

     4. 将原主节点（oldMaster）变成从节点，指向新的主节点

d) 故障转移后的redis sentinel的拓扑结构图
在这里插入图片描述
6. 哨兵机制－故障转移详细流程-确认主节点

a) 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点

b) 选择salve-priority从节点优先级最高（redis.conf）的

c) 选择复制偏移量最大，指复制最完整的从节点

实验环境：

主机	ip
server1（master，sentinel）	172.25.5.1
server2（slave，sentinel）	172.25.5.2
server3（slave，sentinel）	172.25.5.3

配置
1.server1（master），将 sentinel.conf复制到 /etc/redis/，并做相应编辑

[root@server1 ~]# cd redis-5.0.3
[root@server1 redis-5.0.3]# cp sentinel.conf /etc/redis/
[root@server1 redis-5.0.3]# cd /etc/redis/
[root@server1 redis]# ls
6379.conf  sentinel.conf
[root@server1 redis]# vim sentinel.conf 
protected-mode no  ##关闭保护模式

#指定要监控的master，mymaster是定义的master名字，quorum为法定票数2，此处指的是sentinel的数，
只有指定的sentinel同意时才认为sentinel做的决策是有效的，一般大于sentinel数量的半数。可以有多
个master，一组sentinel集群可以监控N个主从复制架构 
sentinel monitor mymaster 172.25.19.1 6379 2

#至少多长时间 连不上才认为主的离线了。单位为ms， 即连接超时时长
sentinel down-after-milliseconds mymaster 10000      （这里我设置为10秒）

# 刚刚设定为新主时，允许同时有多少个从向主发起同步请求。
sentinel parallel-syncs mymaster 1

#当master故障时，把新的从提升为master，多长时间提不上就认为故障转移失败。 
sentinel failover-timeout mymaster 180000

注意：以上参数都在配置文件中可以找到，不用手打

2.将写好的配置文件发到两个slave上的/etc/redis下

[root@server1 redis]# scp sentinel.conf server2:/etc/redis/
[root@server1 redis]# scp sentinel.conf server3:/etc/redis/

3.查看一主两从状态是否良好
4.开启三个节点上的哨兵服务

[root@server1 redis-5.0.3]# redis-server  /etc/redis/sentinel.conf  --sentinel
或者redis-sentinel  /etc/redis/sentinel.conf  &

测试
在server1（master）上把redis服务shutdowm
在这里插入图片描述
哨兵起作用了，显示master漂移到了server3上

在server3上：

在server2：

此时把server1重新启动redis服务，他会成为server3的slave

运维求知者

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Redis-5.0.3主从复制和哨兵

一.Redis主从复制原理和配置1.和MySQL主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。2. Redis主从拓扑a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可...
复制链接

扫一扫