redis_1">为什么会出现redis的哨兵?

• 在redis主从复制的架构中，一旦当master挂掉后，就没有slave去接替他，这时就需要用到哨兵（redis的高可用）

redis_4">redis哨兵

• Sentinel进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用
• 每个哨兵(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且最好为奇数

哨兵机制能做什么？

• 集群监控：负责监控redis master和redis slave进程是否正常工作
• 消息通知：如果某个redis节点有故障，那么哨兵就会发送消息作为报警通知给管理员
• 故障转移：如果master节点挂掉了，会自动转移到slave节点上
• 配置中心：如果故障转移发生了，会通知client客户端新的master地址

什么是主观下线和客观下线？

主观下线

• 当sentinel系统中其中一个sentinel认为redis集群中某个redis宕机了或不可用，则会标记为主观下线

客观下线

• 如果被标记下线的redis节点是master节点，则还需要获得其他sentinel节点的判断，如果超过法定数量的投票，就会认为该master节点不可用，就会标记该master节点为客观下线

哨兵的三个定时监控

• 监控1：哨兵节点每隔10秒向redis master和redis slave节点发送info指令，获取最新的拓扑结构，并更新自身保存的节点信息
• 监控2：哨兵节点每隔2秒向redis指定频道上发送对master主节点状态的判断和自身哨兵节点的信息，其他哨兵节点也会订阅这个频道，来了解对master主节点状态的判断和自身哨兵节点的信息
• 监控3：哨兵节点每隔1秒向redis所有节点和其他哨兵节点发送ping信息，进行心跳检测

master主节点下线后，怎么进行故障转移？

• 这里主要有2步，首先是哨兵系统中会进行leader角色的选举，再由leader哨兵去负责故障转移

leader哨兵的选举

• 当master下线后，每个哨兵都可以选择自己作为leader，将请求发送其他哨兵
• 其他哨兵接受到请求后，可以选择同意或者不同意（根据判定基础决定）
• 如果最终某个哨兵节点获得了超过半数的投票，则该哨兵节点就会成为leader，负责故障转移

故障转移，选举新的master

• 过滤掉与leader哨兵断开连接时间比较长的redis节点
• 优先选择replica-priority小的
• 选择偏移量比较大的（复制的数据越多的）
• 运行id较小的

执行故障转移

• leader向新master节点发送slave no one命令，让它断开与原master的连接，成为独立节点
• leader向其他slave从节点发送slave ip port指令，让它向新master节点进行同步

redis_53">客户端是和哨兵通信还是redis集群通信？

• 其实都有建立通信，情况是这样的：

• client连接集群，首先会连接sentinel系统，然后订阅相关的频道获取redis集群主从切换，切换进度，新master地址等信息
• 拿到master地址后，则会与master建立连接
• 当leader执行了故障转移，选举了新的master后，也会在客户端订阅的频道中发送最新的master地址
• client拿到最新的master地址后，与其建立连接

实验步骤

• 在所有阶段中关闭redis的安全模式

编辑sentinel.conf

protected-mode no  #关闭保护模式
port 26379    #监听端口
daemonize no   #前台模式
pidfile /var/run/redis-sentinel.pid   #sentinel进程pid文件
loglevel notice   #日志级别
logfile ""
dir /tmp
sentinel monitor mymaster 172.25.254.10 6379 2   #创建sentinel监控监控master主机，2表示必须得到2票
sentinel down-after-milliseconds mymaster 10000   #master中断时长，10秒连不上视为master下线
acllog-max-len 128
sentinel parallel-syncs mymaster 1   #发生故障转移后，每次开始同步新master数据的slave数量
sentinel failover-timeout mymaster 180000   #整个故障切换的超时时间为3分钟
sentinel deny-scripts-reconfig yes

• 所有redis集群都要编辑

[root@redis-node1 ~]# vim /etc/redis/sentinel.conf

• sentinel monitor：这是Redis Sentinel命令的一部分，用于开始监控一个新的master主节点
• mymaster：这是你给被监控的master主节点起的名字，可以是任意字符串，但在你的Sentinel配置中需要保持一致。这个名字用于在Sentinel系统内部标识这个主节点
• 172.25.254.10：这是被监控的主节点的IP地址。Sentinel会使用这个地址来与主节点进行通信
• 6379：这是被监控的主节点的端口号。Redis默认使用6379端口
• 2：这是Sentinel判定主节点是否客观下线（objectively down）所需的Sentinel数量（阈值）。只有当至少2个Sentinel判定主节点不可达时，主节点才会被认为客观下线，并触发故障转移流程。通常建议设置为Sentinel总数的半数以上，以确保判断的可靠性

sentinel down-after-milliseconds mymaster 10000 这条命令用于配置Redis Sentinel对名为mymaster的主节点的故障检测时间。具体来说，它定义了Sentinel在多长时间内无法从主节点接收到有效回复后，会将该主节点标记为主观下线（subjectively down）

• 10000：这是超时时间的值，单位为毫秒。在这个例子中，它被设置为10000毫秒，即10秒

#将sentinel.conf发给node2
[root@redis-node1 ~]# scp /etc/redis/sentinel.conf root@172.25.254.20:/etc/redis/

#将sentinel.conf发给node3
[root@redis-node1 ~]# scp /etc/redis/sentinel.conf root@172.25.254.30:/etc/redis/

做sentinel.conf.bak备份

[root@redis-node1 ~]# cp /etc/redis/sentinel.conf /etc/redis/sentinel.conf.bak

[root@redis-node2 ~]# cp /etc/redis/sentinel.conf /etc/redis/sentinel.conf.bak

[root@redis-node3 ~]# cp /etc/redis/sentinel.conf /etc/redis/sentinel.conf.bak

开启哨兵

• 所有redis集群都开启哨兵模式

[root@redis-node1 ~]# redis-sentinel /etc/redis/sentinel.conf

• 以上为前台启动，如果想后台启动，则可以将sentinel.conf中的daemonize设置为yes

#查看生成的配置
[root@redis-node1 ~]# vim /etc/redis/sentinel.conf

[root@redis-node2 ~]# redis-sentinel /etc/redis/sentinel.conf

[root@redis-node3 ~]# redis-sentinel /etc/redis/sentinel.conf

测试

• 将master节点下线

[root@redis-node1 ~]# redis-cli shutdown

• 我们发现node2成为master

• 上node1上线

[root@redis-node1 ~]# /etc/init.d/redis_6379   start

• node1上线后自动成为slave，然后会删除自己原来的所有数据，再去同步新master上的数据

• 先关闭sentinel进程，在将之前备份的bak文件复制回来

#先关闭sentinel进程，在将之前备份的bak文件复制回来
[root@redis-node1 ~]# cp /etc/redis/sentinel.conf.bak /etc/redis/sentinel.conf

• 虽然关闭了sentinel进程，但是新master还是node2

#先关闭sentinel进程，在将之前备份的bak文件复制回来
[root@redis-node2 ~]# cp /etc/redis/sentinel.conf.bak /etc/redis/sentinel.conf

#先关闭sentinel进程，在将之前备份的bak文件复制回来
[root@redis-node3 ~]# cp /etc/redis/sentinel.conf.bak /etc/redis/sentinel.conf

• 重新启动sentinel进程

[root@redis-node1 ~]# redis-sentinel /etc/redis/sentinel.conf

[root@redis-node2 ~]# redis-sentinel /etc/redis/sentinel.conf

[root@redis-node3 ~]# redis-sentinel /etc/redis/sentinel.conf

• 所以只要node2不挂掉，那node2永远都是master

在整个哨兵和主从架构中可能会出现的问题

问题：

• 在生产环境中如果master和slave中的网络出现故障，由于哨兵的存在会把master提出去，当网络恢复后，master发现环境发生改变，master就会把自己的身份转换成slave，master变成slave后会把网络故障那段时间写入自己中的数据清掉，这样数据就丢失了

解决：

• master在被写入数据时会持续连接slave，mater确保至少有2个slave，才允许写入，如果slave数量少于2个，便拒绝写入

临时设定（重启redis后会失效）

#在master中设定
[root@redis-node2 ~]# redis-cli
127.0.0.1:6379> config set min-slaves-to-write 2
127.0.0.1:6379> config get min-slaves-to-write
1) "min-slaves-to-write"
2) "2"

永久配置

#修改master的配置文件，添加一行就行
[root@redis-node2 ~]# vim /etc/redis/6379.conf
min-slaves-to-write 2

#重启redis，不会影响master
[root@redis-node2 ~]# /etc/init.d/redis_6379 restart

127.0.0.1:6379> config get min-slaves-to-write
1) "min-slaves-to-write"
2) "2"


127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
min_slaves_good_slaves:2
slave0:ip=172.25.254.30,port=6379,state=online,offset=290343,lag=1
slave1:ip=172.25.254.10,port=6379,state=online,offset=290343,lag=1
master_failover_state:no-failover
master_replid:96ab7241c9b4b11a1eff2b5eb86df14d5e3b38e7
master_replid2:fc90c49e90a38305862dd41717797f3baca3f8aa
master_repl_offset:290343
second_repl_offset:290288
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:290288
repl_backlog_histlen:56