④Redis服务，主从配置 、sentinel---哨兵模式、全网最细讲解

Redis主从配置

主从简介

1、主从 – 用法

像MySQL一样，redis是支持主从同步的，而且也支持一主多从以及多级从结构。

主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的操作就可以由从服务器来承担。
redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能。
主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。
2、主从同步原理

主从 – 同步原理
从服务器会向主服务器发出SYNC指令，当主服务器接到此命令后，就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器将执行的写指令都缓存在内存中。
在BGSAVE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。

另外，要说的一点是，即使有多个从服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE，然后把持久化好的RDB文件发给多个从服务器。

而在2.8版本之后，redis支持了效率更高的增量同步策略，这大大降低了连接断开的恢复成本。主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后，从服务器会尝试再次与主服务器连接，一旦连接成功，主服务器就会向从服务器发送增量内容。

增量同步功能，需要服务器端支持全新的PSYNC指令。这个指令，只有在redis-2.8之后才具有。

了解

BGSAVE指令:
在后台异步(Asynchronously)保存当前数据库的数据到磁盘。
BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

部署三台机器Redis—主从同步

redis-master----192.168.246.202
redis-slave-1-----192.168.246.203
redis-slave-2-----192.168.246.204
1.首先三台服务器将redis部署完成。
2.编辑master的redis配置文件:
[root@redis-master ~]# cd /data/application/redis/
[root@redis-master redis]# vim redis.conf

主Redis 节点

关闭protected-mode模式，此时外部网络可以直接访问

开启protected-mode保护模式，需配置bind ip或者设置访问密码
启动主节点redis服务

[root@redis-master src]# cd /data/application/redis/src
[root@redis-master src]# nohup ./redis-server ../redis.conf &  会加载此文件中的配置信息

修改slave1的配置文件：

[root@redis-slave-1 ~]# cd /data/application/redis/
[root@redis-slave-1 redis]# vim redis.conf      ---修改如下：

redis-slave-1
redis-slave-2 配置文件都写 主几点的ip地址 还有端口号

5.启动从节点1的redis服务

[root@redis-slave-1 ~]# cd /data/application/redis/src/
[root@redis-slave-1 src]# nohup ./redis-server ../redis.conf &

修改slave2的配置文件

[root@redis-slave-2 ~]# cd /data/application/redis/
[root@redis-slave-2 redis]# vim redis.conf       ---修改如下

redis-slave-1
redis-slave-2 配置文件都写 主几点的ip地址 还有端口号

启动从节点2的redis服务

[root@ansible-web2 ~]# cd /data/application/redis/src/
[root@ansible-web2 src]# nohup ./redis-server ../redis.conf &

或者，配置到了系统管理工具里面直接可以以下操作
重启三台redis

[root@redis-master redis]# systemctl restart redis.service
[root@redis-slave-1 ~]# systemctl restart redis.service
[root@redis-slave-2 ~]# systemctl restart redis.service

测试主从

1.在master上面执行
[root@redis-master redis]# cd src/
[root@redis-master src]# ./redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set name jack
OK
127.0.0.1:6379> get name
"jack"
127.0.0.1:6379>

分别在slave-1和slave-2上面执行:

[root@redis-slave-1 redis]# cd src/
[root@redis-slave-1 src]# ./redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get name
"jack"
127.0.0.1:6379>
[root@redis-slave-2 src]# ./redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get name
"jack"
127.0.0.1:6379>

查看复制状态
master执行：

master执行：
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.246.203,port=6379,state=online,offset=490,lag=0
slave1:ip=192.168.246.204,port=6379,state=online,offset=490,lag=1

slave上面执行：

127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.246.202
master_port:6379
master_link_status:up

注意：从服务器一般默认禁止写入操作：slave-read-only yes

主从同步部署完成！ 但是有一个问题 如果主redis挂了 数据就写不进去拉

Redis-sentinel—哨兵模式

哨兵简介:Redis Sentinel

**Sentinel(哨兵)是用于监控Redis集群中Master状态的工具**，其已经被集成在redis2.4+的版本中是Redis官方推荐的高可用性(HA)解决方案。

2、作用

1)：Master状态检测 
2)：如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave 
3)：Master-Slave切换后，sentinel.conf的监控目标会随之调换 

3、工作模式

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

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

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

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

4、主观下线和客观下线

主观下线：Subjectively Down，简称 SDOWN，指的是当前一个Sentinel 实例对某个redis服务器做出的下线判断。 
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN  判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master  Server下线判断，然后开启failover/故障转移

配置哨兵模式

1.每台机器上修改redis主配置文件redis.conf文件设置：bind 0.0.0.0 —已经操作
2.每台机器上修改sentinel.conf配置文件：修改如下配置

[root@redis-master src]# cd ..
[root@redis-master redis]# vim sentinel.conf

sentinel monitor mymaster 10.0.0.137 6379 2 #当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了。 (slave上面写的是master的ip，master写自己ip)
sentinel down-after-milliseconds mymaster 3000   #单位毫秒
sentinel failover-timeout mymaster 10000   #若sentinel在该配置值内未能完成failover(故障转移)操作（即故障时master/slave自动切换），则认为本次failover失败。
protected-mode no  #关闭加密模式--新添加到sentinel配置文件中

每台机器启动哨兵服务：

[root@redis-master redis]# ./src/redis-sentinel sentinel.conf 
注意:在生产环境下将哨兵模式启动放到后台执行:   nohup  ./src/redis-sentinel sentinel.conf &

将master的哨兵模式退出（Crtl+c），再将redis服务stop了，在两台slave上面查看其中一台是否切换为master:(没有优先级，为随机切换)

^C4854:signal-handler (1564349039) Received SIGINT scheduling shutdown...
4854:X 29 Jul 05:23:59.592 # User requested shutdown...
4854:X 29 Jul 05:23:59.592 # Sentinel is now ready to exit, bye bye...
[root@redis-master redis]# systemctl stop redis.service
或者用kill命令杀死

在slave机器上面查看:

配置完稍等一下可以发现 主节点改变拉 随机改变到 其他节点上拉

查看哨兵

tail -f nuhp.out