（集群）Sentinel哨兵模式

4Sentinel哨兵模式
4.1主从模式的缺陷
当主节点宕机了，整个集群就没有可写的节点了。

由于从节点上备份了主节点的所有数据，那在主节点宕机的情况下，如果能够将从节点变成一个主节点，是不是就可以解决这个问题了呢？

答：是的，这个就是Sentinel哨兵的作用。

4.2哨兵的任务
Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会进行选举，将其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

4.2.1监控（Monitoring）
（1）Sentinel可以监控任意多个Master和该Master下的Slaves。（即多个主从模式）
（2）同一个哨兵下的、不同主从模型，彼此之间相互独立。
（3）Sentinel会不断检查Master和Slaves是否正常。

image.png

4.2.2自动故障切换（Automatic failover）
4.2.2.1Sentinel网络
监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel网络，互相通信并交换彼此关于被监视服务器的信息。下图中，三个监控s1的Sentinel，自动组成Sentinel网络结构。

image.png

疑问：为什么要使用sentinel网络呢？
答：当只有一个sentinel的时候，如果这个sentinel挂掉了，那么就无法实现自动故障切换了。

在sentinel网络中，只要还有一个sentinel活着，就可以实现故障切换。

4.2.2.2故障切换的过程
（1）投票（半数原则）
当任何一个Sentinel发现被监控的Master下线时，会通知其它的Sentinel开会，投票确定该Master是否下线（半数以上，所以sentinel通常配奇数个）。

（2）选举
当Sentinel确定Master下线后，会在所有的Slaves中，选举一个新的节点，升级成Master节点。
其它Slaves节点，转为该节点的从节点。

image.png

（1）投票

image.png

（2）选举
（3）原Master重新上线
当原Master节点重新上线后，自动转为当前Master节点的从节点。

image.png

4.3哨兵模式部署
4.3.1需求
前提：已经存在一个正在运行的主从模式。

另外，配置三个Sentinel实例，监控同一个Master节点。

4.3.2配置Sentinel

image.png

S1哨兵配置如下：

image.png

image.png

S2哨兵配置如下：

image.png

image.png

S3哨兵配置如下：

image.png

image.png

（5）再打开三个xshell窗口，在每一个窗口中，启动一个哨兵实例，并观察日志输出

image.png

核心日志输出：

image.png

4.2.4测试

（1）先关闭6380节点。发现，确实重新指定了一个主节点

image.png

（2）再次上线6380节点。发现，6380节点成为了新的主节点的从节点。

image.png

4.3结论
Sentinel哨兵模式，确实能实现自动故障切换。提供稳定的服务。

4.4注意事项
如果哨兵和redis节点不在同一台服务器上，注意IP绑定的问题。

（1）主从模型，所有的节点，使用ip绑定

image.png

（2）所有的哨兵，也都使用ip去绑定主机

image.png

（3）所有的哨兵，都是通过主节点的ip，去监控主从模型

image.png