目录
[1 哨兵模式介绍](#1 哨兵模式介绍)
[1.1 什么是哨兵模式](#1.1 什么是哨兵模式)
[1.2 sentinel中的三个定时任务](#1.2 sentinel中的三个定时任务)
[2 配置哨兵](#2 配置哨兵)
[2.1 实验环境](#2.1 实验环境)
[2.2 实现哨兵的三条参数：](#2.2 实现哨兵的三条参数：)
[2.3 修改配置文件](#2.3 修改配置文件)
[2.3.1 MASTER](#2.3.1 MASTER)
[2.3.2 SLAVE](#2.3.2 SLAVE)
[2.4 将 sentinel 进行备份](#2.4 将 sentinel 进行备份)
[2.5 开启哨兵模式](#2.5 开启哨兵模式)
[2.6 故障模拟](#2.6 故障模拟)
[3 在整个架构中可能会出现的问题](#3 在整个架构中可能会出现的问题)
[3.1 问题：](#3.1 问题：)
[3.2 解决：](#3.2 解决：)
1 哨兵模式介绍
1.1 什么是哨兵模式
- 哨兵也叫 sentinel，它的作用是能够在后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
Sentinel 进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候， 可以实现Master和Slave服务器的切换，保证系统的高可用，此功能在redis2.6+的版本已引用，Redis的 哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本
每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否"活" 着，如果发现对方在指定配置时间(此项可配置)内未得到回应，则暂时认为对方已离线，也就是所谓的" 主观认为宕机" (主观:是每个成员都具有的独自的而且可能相同也可能不同的意识)，英文名称： Subjective Down，简称SDOWN
有主观宕机，对应的有客观宕机。当"哨兵群"中的多数Sentinel进程在对Master主服务器做出SDOWN 的 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是"客观宕机"(客观:是不依赖于某种意识而已经实际存在的一切事物)，英文名称是： Objectively Down， 简称 ODOWN
通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改 相关配置，并开启故障转移（failover）
Sentinel 机制可以解决master和slave角色的自动切换问题，但单个 Master 的性能瓶颈问题无法解决,类 似于MySQL中的MHA功能
Redis Sentinel中的Sentinel节点个数应该为大于等于3且最好为奇数
1.2 sentinel****中的三个定时任务
- 每10秒每个 Sentinel 对 master 和 slave 执行
info命令，以发现 slave 节点并确认主从关系。这有助于 Sentinel 了解集群的当前状态，并确保主从关系正确。 - 每2秒每个 Sentinel 通过 master 节点的 channel 交换信息（pub/sub），通过
sentinel __:hello频道交互，交互对节点的"看法"和自身信息。这有助于 Sentinel 了解其他 Sentinel 的状态，并确保集群中的所有 Sentinel 都在正常工作。 - 每1秒每个 Sentinel 对其他 Sentinel 和 Redis 执行 ping 命令，以检查它们的可用性。这有助于 Sentinel 了解集群中所有节点的当前状态，并确保它们都在正常工作。
2 配置哨兵
2.1 实验环境
| 节点名称 | 角色 | IP地址 |
|---|---|---|
| node1 | MASTER | 192.168.239.10 |
| node2 | SLAVE-1 | 192.168.239.20 |
| node3 | SLAVE-2 | 192.168.239.30 |
2.2 实现哨兵的三条参数：
bash
sentinel monitor mymaster 192.168.239.10 6379 2
sentinel down-after-milliseconds mymaster 10000
sentinel parallel-syncs mymaster 1
# sentinel monitor mymaster 192.168.239.10 6379 2：
# Sentinel 监控名为 mymaster 的主节点，其地址为 192.168.239.10:6379，
# 并且要求至少有两个 Sentinel 认为主节点失效才会进行故障切换。
# sentinel down-after-milliseconds mymaster 10000：
# Sentinel 在经过 10000 毫秒（即 10 秒钟）之后，
# 如果主节点没有响应，则认为主节点已经失效。
# sentinel parallel-syncs mymaster 1：
# 在故障切换过程中，最多允许一个从节点同时进行同步。2.3 修改配置文件
2.3.1 MASTER
bash
[root@node-1 ~]# vim /etc/redis/redis.conf
bind * -::* # 允许所有IP所有端口连接
protected-mode no # 关闭安全模式即密码验证
sentinel monitor mymaster 192.168.239.10 6379 2
sentinel down-after-milliseconds mymaster 10000
sentinel parallel-syncs mymaster 12.3.2 SLAVE
bash
[root@node-2 ~]# vim /etc/redis/redis.conf
bind * -::* # 允许所有IP所有端口连接
protected-mode no # 关闭安全模式即密码验证
replicaof 192.168.239.10 6379 # 向 MASTER 进行同步
sentinel monitor mymaster 192.168.239.10 6379 2
sentinel down-after-milliseconds mymaster 10000
sentinel parallel-syncs mymaster 1
bash
[root@node-3 ~]# vim /etc/redis/redis.conf
bind * -::* # 允许所有IP所有端口连接
protected-mode no # 关闭安全模式即密码验证
replicaof 192.168.239.10 6379 # 向 MASTER 进行同步
sentinel monitor mymaster 192.168.239.10 6379 2
sentinel down-after-milliseconds mymaster 10000
sentinel parallel-syncs mymaster 1参数说明：
monitor：监控
redismaster：为监控对象起的服务名称
2：为至少有多个个哨兵同意迁移的数量
是一条 Redis Sentinel 的命令，它告诉 Sentinel 监控名为
mymaster的主节点，其地址为192.168.239.10，并且要求至少有两个 Sentinel 认为主节点失效才会进行故障切换。
2.4 将 sentinel 进行备份
由于执行哨兵模式的时候Redis会修改sentinel.conf配置文件，所以将他先备份一份
bash
[root@node-1 redis]# cp sentinel.conf sentinel.conf.bak
[root@node-2 redis]# cp sentinel.conf sentinel.conf.bak
[root@node-3 redis]# cp sentinel.conf sentinel.conf.bak2.5 开启哨兵模式
2.6
bash
[root@node-1 redis]# redis-sentinel /etc/redis/sentinel.conf
[root@node-2 redis]# redis-sentinel /etc/redis/sentinel.conf
[root@node-3 redis]# redis-sentinel /etc/redis/sentinel.conf
2.6 故障模拟
停止node-1 的Redis
bash
[root@node-1 ~]# systemctl stop redis_6379.service 在node-2能发现MASTER从node-1 变为了 node-2
查看 node-2 的状态
bash
[root@node-2 ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.239.30,port=6379,state=online,offset=28084,lag=1
master_failover_state:no-failover
master_replid:5042333e8ac488fd7fd05a38bbd99e3f1a4f4528
master_replid2:6cae489b55bf61b8432df467e53d93081effc1ce
master_repl_offset:28227
second_repl_offset:18125
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:28227发现已经转换为MASTER了
3 在整个架构中可能会出现的问题
3.1 问题：
在生产环境中如果master和slave中的网络出现故障，由于哨兵的存在会把master提出去
当网络恢复后，master发现环境发生改变，master就会把自己的身份转换成slave
master变成slave后会把网络故障那段时间写入自己中的数据清掉，这样数据就丢失了。
3.2 解决：
master在被写入数据时会持续连接slave，mater确保有2个slave可以写入我才允许写入
如果slave数量少于2个便拒绝写入
bash
#在matster中设定
[root@node2 ~]# redis-cli
127.0.0.1:6379> CONFIG GET min-slaves-to-write
1) "min-slaves-to-write"
2) "0"
127.0.0.1:6379> CONFIG set min-slaves-to-write 2
OK
127.0.0.1:6379> CONFIG GET min-slaves-to-write
1) "min-slaves-to-write"
2) "2"
#如果要永久保存写到配置文件中/etc/redis/6379.conf