redis主从模式和哨兵模式

一.redis主从模式

1.1 概述

主从模式:是三种集群方式里最简单的。它主要是基于Redis的主从复制特性架构的。通常我们会设置一个主节点，N个从节点;默认情况下，主节点负责处理使用者的IO操作，而从节点则会对主节点的数据进行备份，并且也会对外提供读操作的处理。

1.2 特点

1. 主从模式下，当某一节点损坏时，因为其会将数据备份到其它Redis实例上，这样做在很大程度上可以恢复丢失的数据。

2. 主从模式下，可以保证负载均衡，这里不再叙说了

3. 主从模式下，主节点和从节点是读写分离的。使用者不仅可以从主节点上读取数据，还可以很方便的从从节点上读取到数据，这在一定程度上缓解了主机的压力。

4. 从节点也是能够支持写入数据的，只不过从从节点写入的数据不会同步到主节点以及其它的从节点下。

从以上，我们不难看出Redis在主从模式下，必须保证主节点不会宕机——一旦主节点宕机，其它节点不会竞争称为主节点，此时，Redis将丧失写的能力。这点在生产环境中，是致命的

二.redis主从搭建

2.1 搭建环境

主机	ip
master	20.0.0.10
slave1	20.0.0.11
slave2	20.0.0.12

2.2 安装redis

每台服务器都需要安装

2.3 修改配置文件

master

[root@master src]# vim /etc/redis/6379.conf
#70行 修改监听地址为20.0.0.10 master地址
bind 20.0.0.10
#137行 开启守护进程
daemonize yes
#172行 修改日志文件目录
logfile /var/log/redis_6379.log
#264行 修改工作目录
dir /var/lib/redis/6379
#700行 开启AOF持久化功能
appendonly yes

重启redis服务
查看端口是否开启

slave1

[root@slave1 src]# vim /etc/redis/6379.conf
#70行 修改监听地址为20.0.0.11 slave1地址
bind 20.0.0.11
#137行 开启守护进程
daemonize yes
#172行 修改日志文件目录
logfile /var/log/redis_6379.log
#264行 修改工作目录
dir /var/lib/redis/6379
#700行 开启AOF持久化功能
appendonly yes
#287 修改IP和端口 指向master
replicaof 20.0.0.10 6379

查看端口

slave2

[root@slave1 src]# vim /etc/redis/6379.conf
#70行 修改监听地址为20.0.0.12 slave2地址
bind 20.0.0.12
#137行 开启守护进程
daemonize yes
#172行 修改日志文件目录
logfile /var/log/redis_6379.log
#264行 修改工作目录
dir /var/lib/redis/6379
#700行 开启AOF持久化功能
appendonly yes
#287 修改IP和端口 指向master
replicaof 20.0.0.10 6379

查看端口

2.4 查看日志文件

[root@master utils]# vi /var/log/redis_6379.log 

2.5 master上验证从节点

2.6 验证效果

在master上插入数据

slave1和slave2上分别查看

三. Sentinel 哨兵模式

3.1 概述

Sentinel 哨兵是基于主从模式做的一定变化，它能够为Redis提供了高可用性。在实际生产中，服务器难免不会遇到一些突发状况：服务器宕机，停电，硬件损坏等。这些情况一旦发生，其后果往往是不可估量的。而哨兵模式在一定程度上能够帮我们规避掉这些意外导致的灾难性后果。其实，哨兵模式的核心还是主从复制。只不过相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制——从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。

3.2 sentinel特点

1. 监控：它会监听主服务器和从服务器之间是否在正常工作。

2. 通知：它能够通过API告诉系统管理员或者程序，集群中某个实例出了问题。

3. 故障转移：它在主节点出了问题的情况下，会在所有的从节点中竞选出一个节点，并将其作为新的主节点。

4. 提供主服务器地址：它还能够向使用者提供当前主节点的地址。这在故障转移后，使用者不用做任何修改就可以知道当前主节点地址。

sentinel，也可以集群，部署多个哨兵，sentinel可以通过发布与订阅来自动发现Redis集群上的其它sentinel。sentinel在发现其它sentinel进程后，会将其放入一个列表中，这个列表存储了所有已被发现的sentinel。

集群中的所有sentinel不会并发着去对同一个主节点进行故障转移。故障转移只会从第一个sentinel开始，当第一个故障转移失败后，才会尝试下一个。当选择一个从节点作为新的主节点后，故障转移即成功了(而不会等到所有的从节点配置了新的主节点后)。

当竞选出新的主节点后，被选为新的主节点的从节点的配置信息会被sentinel改写为旧的主节点的配置信息。完成改写后，再将新主节点的配置广播给所有的从节点。如果原master重连，并不会成为master。

3.3 Sentinel的工作方式:

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 搭建

4.1 修改配置文件

每一台服务器都需要修改

[root@master ~]# vi redis-5.0.7/sentinel.conf
17行/protected-mode no                                  #关闭保护模式
26行/daemonize yes                                      #指定sentinel为后台启动
36行/logfile "/var/log/sentinel.log"                    #指定日志存放路径
65行/dir "/var/lib/redis/6379"                          #指定数据库存放路径
84行/sentinel monitor mymaster 20.0.0.10 6379 2         #至少几个哨兵检测到主服务器故障了，才会进行故障迁移，全部指向masterIP
113行/sentinel down-after-milliseconds mymaster 30000    #判定服务器down掉的时间周期，默认30000毫秒（30秒）
146行/sentinel failover-timeout mymaster 180000         #故障节的的最大超时时间为180000（180秒）

4.2开启哨兵模式

先开启master，在开启slave

[root@localhost opt]# redis-sentinel redis-5.0.7/sentinel.conf &

4.3查看哨兵信息

[root@localhost opt]# redis-cli -h 20.0.0.10 -p 26379 info Sentinel

4.4 模拟故障

查看进程号，并杀死master上的进程号

[root@localhost opt]# ps -ef | grep redis    

4.5 查看信息验证结果

[root@localhost opt]# redis-cli -p 26379 INFO Sentinel