哨兵（sentinal）

哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。

1.Redis哨兵主要功能

（1）集群监控：负责监控Redis master和slave进程是否正常工作

（2）消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员

（3）故障转移：如果master node挂掉了，会自动转移到slave node上

（4）配置中心：如果故障转移发生了，通知client客户端新的master地址

2.Redis哨兵的高可用

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

1. 哨兵机制建立了多个哨兵节点(进程)，共同监控数据节点的运行状况。
2. 同时哨兵节点之间也互相通信，交换对主从节点的监控状况。
3. 每隔1秒每个哨兵会向整个集群：Master主服务器+Slave从服务器+其他Sentinel（哨兵）进程，发送一次ping命令做一次心跳检测。

部署

主机

1.  安装 参考：https://blog.csdn.net/zhuchunyan_aijia/article/details/78476151

2. 修改配置文件  vi /usr/local/redis/etc/redis.conf   主机：  168上

#1、redis默认不是以线程守护的方式运行的，如需要调整至线程守护的方式，请把

daemonize no  =>  daemonize yes

#2、把默认端口6379改为其他

port 6379   => port 9500 

#3、bind会限制能够访问redis的地址，默认（127.0.0.1）是指本地才能访问。如果要放开redis，如要搭建redis集群的话，要把bind注释掉；同时要把protected-mode从yes改为no

#bind 127.0.0.1

protected-mode yes  => protected-mode no

#4、把PID文件名改成跟修改后的PORT一致

pidfile /var/run/redis_9500.pid

#5、设定日志文件路径

logfile "/var/run/redis/redis.log"

#6. 指定本地数据库存放目录
    dir ./
#修改dir ./为绝对路径,  
#默认的话redis-server启动时会在当前目录生成或读取dump.rdb  
#所以如果在根目录下执行redis-server /etc/redis.conf的话,  
#读取的是根目录下的dump.rdb,为了使redis-server可在任意目录下执行  
#所以此处将dir改为绝对路径  
dir /usr/local/redis  

#7. 修改appendonly为yes  
#指定是否在每次更新操作后进行日志记录，  
#Redis在默认情况下是异步的把数据写入磁盘，  
#如果不开启，可能会在断电时导致一段时间内的数据丢失。  
#因为 redis本身同步数据文件是按上面save条件来同步的，  
#所以有的数据会在一段时间内只存在于内存中。默认为no  
appendonly yes  

#8. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
requirepass foobared

# 如果设置了密码：主从都要有requirepass  和  masterauth。因为哨兵模式下，主服务器会变成从服务器。
masterauth  foobared

#9. redis默认有db0~db15之多，配置db
databases 16

3.   修改配置文件  vi /usr/local/redis/etc/redis.conf   主机：  181,129上

配置与168上一样，增加

#因为这里是以 192.168.31.168 这台作为主库，因此只需要修改 181 和 129 这两台从库的以下配置项（只需要修改两个从 redis 实例）

# 这里请注意，5.0 版本之前是使用 slaveof，5.0 版本之后的配置使用 replicaof，但是因为向下兼容的原则，就算你在 5.0 的版本中使用 slaveof 也不会有问题，但一般建议有新的就用新的吧，否则某天如果突然不支持旧的 slaveof 就 GG 了。

replicaof 192.168.31.168 9500

修改： 

port 6379   => port 9501 和 9502  其实3台机器部署，端口可以一样 

4. 启动服务，进入 3台redis机器中执行

redis-server redis.conf

检查是否启动成功：命令：ps -ef | grep redis

5、查看主从关系是否配置成功,执行命令：

bin/redis-cli -p 9500

auth 密码

info replication

[root@centos7a src]# ./redis-cli -h 192.168.31.168 -p 9500

192.168.31.168:9500> info replication

Replication

role:master

connected_slaves:2

slave0:ip=192.168.31.181,port=9501,state=online,offset=2235966,lag=1

slave1:ip=192.168.31.129,port=9502,state=online,offset=2235966,lag=1

master_replid:1df20ecc0df92307ef811e9bd81cc09e131725c7

master_replid2:0000000000000000000000000000000000000000

masterreploffset:2236538

........

 

[root@mimy-centos7b src]# ./redis-cli -h 192.168.31.181 -p 9501

192.168.31.181:9501> info replication

Replication

role:slave

master_host:192.168.31.168

master_port:9500

masterlinkstatus:up

masterlastio_seconds_ago:0

mastersyncin_progress:0

slavereploffset:2317523

........

 

[root@localhost src]# ./redis-cli -h 192.168.31.129 -p 9502

192.168.31.129:9502> info replication

Replication

role:slave

master_host:192.168.31.168

master_port:9500

masterlinkstatus:up

masterlastio_seconds_ago:1

mastersyncin_progress:0

slavereploffset:2336225

........

 6、//主从复制配置好以后，再配置哨兵模式   修改每个 sentinel.conf

port 26379

# 是否后台运行    设置成后台运行

daemonize yes

# 运行时的pid文件  

pidfile /var/run/redis-sentinel.pid 

# sentinel日志文件  

logfile  "/var/log/sentinel.log"

# 工作目录  

dir /tmp

# 这里定义主库的IP和端口，还有最后的2表示要达到2台sentinel认同才认为主库已经挂掉（即客观失效），后面科普  

sentinel monitor mymaster 192.168.31.168 9500 2

# 主库在30000毫秒（即30秒）内没有反应就认为主库挂掉（即主观失效）  

sentinel down-after-milliseconds mymaster 30000

# 若新主库当选后，允许最大可以同时从新主库同步数据的从库数  

sentinel parallel-syncs mymaster 1    

# 若在指定时间（即180000毫秒，即180秒）内没有实现故障转移，则会自动再发起一次  

sentinel failover-timeout mymaster 180000

sentinel deny-scripts-reconfig yes           

//如果设置了密码，这块是要写的
 sentinel auth-pass mymaster 密码   

7. 启动3台redis-sentinel

bin/redis-sentinel sentinel27269.conf 
bin/redis-sentinel sentinel27270.conf 
bin/redis-sentinel sentinel27271.conf

检查是否启动成功：命令：ps -ef | grep redis

查看哨兵信息：

/redis-cli -h 192.168.31.168 -p 26379

info sentinel

8. 启动顺序

使用以下命令启动 Redis 和 Sentinel，具体顺序为：Redis（主）-> Redis（从）->Redis（从）->Sentinel（1）->Sentinel（2）->Sentinel（3）

9. 验证数据同步

#1、一开始三台机都是同步的，没有数据的；

192.168.31.168:9500> KEYS *

(empty list or set)

192.168.31.181:9501> keys *

(empty list or set)

192.168.31.129:9502> keys *

(empty list or set)

#2、在主库插入（KEY1,CHAOS MONKEY）

192.168.31.168:9500> SET KEY1 'CHAOS MONKEY'

OK

#3、查询另外两个从库是否同步了

192.168.31.181:9501> get KEY1

"CHAOS MONKEY"

192.168.31.129:9502> GET KEY1

"CHAOS MONKEY"

从 129 这台机的日志（/var/run/redis/redis.log）看，数据正在从 168 同步到 129 的从库（截图一）。另外，相同的同步的行为也发生在从 168 到 181 的从库（截图二）。

10. 高可用验证

首先，我们通过命令“./redis-cli -h 192.168.31.168 -p 26379 info sentinel”随便从一台机看看 sentinel 的情况，目前主库是 192.168.31.168。 

接着我们尝试模拟主库崩溃，先把 168 的主库停掉，然后通过 sentinel.log 日志发现主库已经从 168 换成 181。

首先，181 发现 168 下线，这是主观失效；因为我们在 sentinel.conf 中的设置了 sentinel monitor mymaster 127.0.0.1 6379 2 ， 这里最后的 2 代表需要 2 个哨兵认为主库下线才算是真正下线（即客观失效）然后再进行选举；

接着，129 或者 168 的哨兵也发现 168 下线，已经达到 2 台，因此就把 168 主库设成下线（客观失效），开始选举；

接着，开始选举，最终 181 被选举成主库。

 登录到 181 的 redis 上，通过 INFO REPLICATION 可以看到 181 也确实变成主库，129 变成 181 的从库

 这个时候我们继续尝试一下新增 KEY，从以下结果可以看出 129 是能够正常从 181（新主库）同步数据

192.168.31.181:9501> keys *

1) "KEY1"

2) "KEY2"

3) "KEY3"

 

192.168.31.129:9502> keys *

1) "KEY3"

2) "KEY2"

3) "KEY1"

 

192.168.31.181:9501> set KEY4 BUTTERFLY

OK

192.168.31.181:9501> keys *

1) "KEY1"

2) "KEY4"

3) "KEY2"

4) "KEY3"

 

192.168.31.129:9502> keys *

1) "KEY3"

2) "KEY2"

3) "KEY4"

4) "KEY1"