319-Redis（哨兵）

哨兵

1、哨兵简介

1.1、主机宕机

在开启主从复制后，master宕机了，哪个slave来代替master，需要做哪些事情?

• 关闭master和所有slave
• 找一个slave作为master
• 修改其他slave的配置，连接新的master
• 启动新的master与slave
• 全量复制* N+部分复制* N

上面步骤存在的问题：

• 谁来确认master宕机了？
• 关闭期间的数据服务谁来承接？
• 找一个主？怎么找法？
• 修改配置后，原始的主恢复了怎么办？

谁来负责上面这些事情？哨兵！（可以看成是一双眼睛盯着它们干活！）

1.2、哨兵

哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

1.3、哨兵的作用

1、监控：

• 不断的检查master和slave是否正常运行；
• master存活检测、master与slave运行情况检测。

2、通知（提醒）

• 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。

3、自动故障转移

• 断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址。

注意：

• 哨兵也是一台redis服务器，只是不提供数据服务；
• 通常哨兵配置数量为单数（双数投票竞选会出现打平）

2、哨兵模式搭建

• 配置一拖二的主从结构
• 配置三个哨兵（配置相同，端口不同） 参看sentinel.conf
• 启动哨兵

redis-sentinel sentinel-端口号.conf

port： 哨兵本身也是一个服务，对外也是有一个端口的！
dir： 对应的哨兵的工作信息存储在这个文件夹中

sentinel monitor mymaster 127.0.0.1 6379 2 ：表示哨兵监控的服务器，2表示有两个哨兵认为这个服务器挂了！（mymaster是主服务器master）

sentinel sentinel down-after-milliseconds mymaster 30000：表示主master服务器mymaster连接30s不响应，哨兵就认为你这个服务器挂了！
sentinel parallel-syncs mymaster 1：　mymaster挂掉后，将 slave 中的某个节点中提升为 master 后，剩余节点立即重连新 master 的数量，进行数据同步！（数值越大，要求网络资源越高，要求约小，同步时间约长）
sentinel failover-timeout mymaster 9000：在进行同步时，太慢也不能接收，这个值表示多长时间同步完成是有效的！没有完成超过时间就无效了。

将上面的配置复制一下并移动下位置：

将哨兵工作信息的存储位置修改下：

再复制修改另外两个哨兵配置文件：

再看看master和salve1、slave2：

我们再创建一个6381也就是slave2：

---

清除其他文件，现在conf文件夹只剩下这6个配置文件：

将data文件夹中也清空：

---

下面我们就可以测试哨兵了！

先启动主机master，再启动从机slave1、slave2，最后启哨兵！

---

1、启动master：

---

2、启动slave1和slave2：

slave1:


slave2：

---

哨兵1：

可以看到master和slave的信息；

可以使用客户端连接哨兵1的服务器：（注意更换端口为哨兵所在的端口）

get和set是不允许的，只能执行哨兵的指令！

输入info：

可以看到sentinel = 1，表示只用1个哨兵！

再次查看下哨兵1的配置文件：

加入了id和一些主从的信息！（可以知道，一旦启动哨兵，主从信息是会发生变化的！）

---

我们再启动第2个哨兵：

每启动一个新哨兵，哨兵之间是能相互识别的！

可以看到在哨兵2中有哨兵1的id信息：

哨兵1的服务器上也有哨兵2的ID信息，哨兵之间相互识别：

我们此时再打开哨兵1的配置文件，可以看到配置文件中又加入了一个新的ID，就是哨兵2的ID信息：

---

我们再启动哨兵3：
可以看到哨兵3识别到了哨兵1和哨兵2！哨兵123都互相识别了！

在哨兵1的配置文件中，又会增加哨兵2、3的ID信息：

---

检查主从复制是否运行正常：


OK的！

---

哨兵怎么操作？

当主master挂掉的时候，从slave会接手它的工作；

1、ctrl + c将主服务器停掉；
此时因为设置的响应时间30s，过了30s master不响应，哨兵就认为master挂掉了

哨兵1上服务器上新的日志信息：

• 1、sdown：表示其中有一个人认为6379这个服务器下线了；

• 2、odown：所有哨兵都去看，然后都认为它下线了；

• 3、发起了一轮投票，来选择哪个slave服务器作为master；

• 4、推选出了6381为新的master；

• 5，6、将6381作为master，设置6379、6380为其slave；

• 7、sdown：将6379下线！

3、哨兵工作原理

哨兵主要做的事是 主从切换。

哨兵在进行主从切换过程中经历三个阶段：

• 监控
• 通知
• 故障转移

3.1、阶段一：监控阶段

哨兵 先连接 master，给master发送info，就可以获得master的信息，同时也可以获得slave中的信息；

根据上面获得的salve信息，再给slave发送info，获取slave详细信息！

上图中的过程：

1、获取master信息，当然也获得了slave的部分信息；

2、为了方便哨兵和master以及slave命令交换，建立了一个cmd连接！

还保存了所有的哨兵状态：

还保存了Redis实例的信息：

3、根据第2步中获取的slave信息，再取获取每个slave的详细信息！

4、又一个哨兵连接进来了，会建立cmd通道，获取master和slave的信息，

同时，自己保存的哨兵状态会更新为2个，会加上之前的那个哨兵信息：

5、各个哨兵之间会建立一个发布-订阅机制，用来同步各自获得的信息，且会互相ping，看看对方是否在线！

简单小结：

• 哨兵会向master、slave、以及其他哨兵 要状态；
• 哨兵之间会有一个发布-订阅通道，哨兵会在里面发布信息、订阅信息、收信息、同步信息！

3.2、阶段二：通知阶段

• 三个哨兵组成了一个群体，它们之间进行信息互通；
• master和slave之间正常干活；
• 哨兵会根据它们和master、slave之间建立的cmd连接获取master和slave状态信息！不管是哪个哨兵获取到，都会将信息回传，然后再哨兵之间共享信息！

3.3、阶段三：故障转移阶段

现在是出现故障了：

1、sentinel1给master发消息，master不理他，sentinel1不停的一直在发；

哨兵1就标记master已经断开连接了：

哨兵1会在哨兵组成的内网中通知master已经挂了！

其他哨兵接到通知后，自己也会尝试发送hello，看看到底有没有掉线！确认下哨兵1的消息对不对！

此时master的状态标记为O_DOWN，一个哨兵认为master下线称为S_DOWN（主观下线），只要超过半数的哨兵都认为下线，就记为O_DOWN（客观下线）！

---

确定master出错后，现在就要派哨兵去解决问题了，派谁去？

竞选投票机制，其他没参选的哨兵，先收到谁的竞选信息，就将票投给谁！

假如得到的票数是哨兵总数量的一半及以上，就是这个哨兵，没有的话继续投票！

这样就选取出来一个出来故障信息的哨兵了！

---

接下来，正式处理故障信息，也就是挑选slave作为master；

挑选salve作为master的原则：

• 在线的
• 响应快的（网络好）
• 与原master断开时间久的（也表示网络好，master一断开slave就知道了）
• 优先原则
  • 优先级
  • offset（越大，说明之前同步的效果好）
  • runid（offset一样，就看runid谁小！）

接下来：

• 就是告诉新master你是master，不要再做任何服务器的slave了；
• 再向其他机器说明那个机器是master，让这些slave去连接master！

4、总结

1、监控

• 同步信息

2、通知

• 保持联通

3、故障转移

• 发现问题
• 竞选负责人（选出一个哨兵去处理故障）
• 优选新master
• 新master上任，其他slave切换master，原master作为slave故障回复后连接

重新启动6379这个服务器：

可以看到6379是以slave的身份连接上来了！