redis之哨兵监控

1.什么是redis的哨兵监控

Redis的哨兵监控用于监控Redis主从集群的健康状态，保障Redis集群的高可用性。哨兵监控会定期检查Redis节点的运行状态，如果发现主节点宕机或出现故障，哨兵监控会自动进行主从切换，将从节点升级为新的主节点，以保证Redis集群的正常运行。

2.为什么要有哨兵监控

前一章节我们说到了redis的主从复制，没了解的过的小伙伴可以看一下之前关于主从复制的文章
https://blog.youkuaiyun.com/weixin_45116867/article/details/139860736?spm=1001.2014.3001.5501
主从复制的缺点就在于当redis的主节点宕机后，从节点不会主动上位，只能等待人工干预重启，这个方式在生产环境是不可接受的，因此需要一种监控机制，当redis主节点宕机后，能够自动恢复

3.哨兵集群搭建的细节

第一点，哨兵也需要部署多个，避免单个哨兵宕机，无法监控redis主节点状态
第二点，哨兵的个数需要是奇数个，为了方便后续哨兵判断redis客观下线，少数服从多数
第三点，redis主从复制加哨兵监控，理论上最少需要6台服务器资源搭建（1个redis主节点，2个redis从节点，3个哨兵监控节点）

4.哨兵监控的开启方式

配置文件sentinel.conf
首先进入到redis的安装目录，找到配置文件sentinel.conf

这里注意，不要直接修改原有的sentinel.conf配置文件，使用cp命令复制一份进行修改，这样的好处就在于当配置文件修改坏了，还有备份进行恢复

sentinel.conf的配置项
核心配置
sentinel monitor redis主节点名称 (随便叫，默认mymaster) redis主节点ip redis主节点端口 投票数x（投票数的意思是当有x个哨兵认为redis主节点主观下线，就认定redis主节点宕机，将会执行故障转移）
这里需要注意sentinel monitor配置的三个哨兵的监控的redis主节点必须一样
sentinel auth-pass redis主节点名称 (随便叫，默认mymaster) redis主节点密码
这里我默认各位小伙伴有三台不同的服务器，上述的配置分别在三台服务器修改好
执行 ./redis-sentinel sentinel.conf配置文件路径 启动哨兵监控服务

使用ps -ef|grep 命令查一下哨兵进程，正常启动即可

6.哨兵监控服务的日志解读（一）

上述第四步我们配置了哨兵监控服务启动日志的所在目录，我们用vim命令查看下日志里所记载的内容

7.哨兵监控验证

我们使用redis客户端连接三个redis实例A（主节点）B（从节点1）C（从节点2）
分别执行下info replication命令，查看下节点信息，确认A属于主节点，B和C属于从节点
然后，我们在主节点执行shutdown命令
现在主节点宕机了，过了一会我们在B（从节点1）C（从节点2）执行info replication命令发现
从节点B（或者C）变成了redis的主节点
证明哨兵监控到了原redis主节点A宕机，并且重新指定了一个原从节点上任为新的主节点

8.关于哨兵监控的思考

1.主节点宕机后，从节点的数据还在吗？
我们在主节点宕机之前，搭建好主从复制集群，在主节点写入数据set k1 v1，从节点是能成功同步并且能够get k1 对应的值
此时我们在主节点执行shutdown命令，从节点依然能够get k1 对应的值
所以这题的答案是：主节点宕机后，从节点的数据还在
2.主节点宕机后，会有新的节点成为主节点吗？
这个问题在第7部分我们已经验证过了
答案是：主节点宕机后，会有新的节点成为主节点
3.当原来的主节点恢复后，他还会成为主节点吗？
答案是：不会
原来的主节点恢复后，他会重新成为一个从节点，而不是继续当主节点

9.回看配置文件

当哨兵监控重新选择新的redis主节点之后，我们再看一下redis的配置文件和sentinel 配置文件
redis配置文件的变化，redis配置文件被重写了
看一下redis配置文件的最后，之前从节点配置文件中的replicaof配置的是宕机的redis主节点ip和端口
当主节点宕机后，从节点配置文件中的replicaof配置变成了另一个从节点的ip和端口
也就是说，当前从节点已经成为了另一个从节点的slave
另一个从节点变成了新的主节点

sentinel 配置文件的变化，sentinel 配置文件也被重写了
之前哨兵监控的是宕机的redis实例，当该实例宕机后，sentinel 配置文件中监控的redis实例ip和端口也发生了变化
开始监控新的redis主节点
现在有redis主节点A，从节点B，从节点C
哨兵1，哨兵2，哨兵3
哨兵集群全部监控的都是redis主节点A
redis主节点A宕机后
三个redis实例的配置文件还有哨兵的配置文件都被重写了
三个哨兵开始监控新的redis主节点
三个redis实例的配置文件中关于主从节点的replicaof 参数也发生变化
新redis主节点配置文件中，不再有replicaof 参数
从节点redis配置文件中，replicaof 参数被重写为新的redis主节点的ip和端口

10.哨兵监控服务的日志解读（二）
我们用vim命令再次查看下日志里所记载的内容
记录了当前哨兵监控redis主节点的相关信息

11.主观下线和客观下线

主观下线：
单个哨兵在指定时间内收不到redis服务端的响应，那么当前哨兵就会认为redis主节点宕机，主观下线。
哨兵会定时向redis服务端发送ping命令，如果redis服务端无法在规定时间内响应（默认30s，可在sentinel 配置文件中修改），当前哨兵就会主观（SDOWN）认为redis主节点宕机

客观下线：
在生产环境中，可能会存在网络阻塞，网络抖动等现象，实际redis主节点并没有宕机，由于网络原因导致哨兵收不到redis服务端的响应，因此就需要多个哨兵同时认为redis主节点宕机，才会去重新选择新的redis主节点，这里也解释了文章中第3部分讲到的，哨兵的个数需要是基数，我们以3个哨兵为例，当2个（我们在sentinel 配置文件中 配置的sentinel monitor参数，其中票数配置的2）哨兵认为redis主节点宕机了，那么就是客观(ODOWN)下线

12.哨兵选举

我们启动了3个哨兵监控服务，分别是哨兵1，哨兵2，哨兵3
那么当redis主节点宕机后，达到了客观下线的条件，哪个哨兵实例去决定把redis从节点转换为新的redis主节点呢？
是3个哨兵同时决定吗？
答案是只有一个哨兵决定
当redis主节点宕机后，达到了客观下线的条件，哨兵内部会投票，选举出一个leader，由哨兵leader来决定，下一个新的redis主节点是谁
选举采用的算法是Raft算法

13.redis从节点有多个，凭啥“你”当新的主节点？

这里从节点上位，遵循三步
优先级-偏移量-run id
优先级在redis的配置文件中有配置，越小优先级越高

如果从节点的redis优先级都是一样的，那么进行第二步
看同步偏移量，之前我们将redis主从复制的时候，讲到了redis从节点的复制偏移量
比如从节点B的复制偏移量为7，从节点C的复制偏移量为8，那么认为从节点C中的数据更全面，将从节点C转为新的redis主节点
如果同步偏移量也一样，那么进行第三步
将redis服务的进程号转换为ASCⅡ码，进行比较

14.哨兵+redis主从的缺点

一句话：哨兵+redis主从模式不能保证数据不丢失
因为当redis主节点宕机后，哨兵内部会选举，会选新的redis主节点，会网络重置，等等一系列操作，都是需要时间的，保守估计，从原redis主节点宕机到新的redis主节点上线，需要10s，那么在这10s内，客户端是仍然不能写入的，也就是说，这10s之内的数据就丢失了