redis的哨兵模式在开发中起到重要作用，它能够监控服务器，获取主机的工作状态是否正常，保证系统的高可用性，那redis的哨兵模式如何应用?下面来我们就来给大家讲解一下。
Redis Sentinel 哨兵模式适合于在 Linux 系统中使用，所以下面的应用都基于 Ubuntu 实现。
1) 安装sentinel
Sentinel 需要作为插件单独安装，安装方式如下：
sudo apt install redis-sentinel
2) 搭建主从模式
接下来，在本地环境使用主从模式搭建一个拥有三台服务器的 Redis 集群，命令如下所示：
启动6379的redis服务器作为master主机: sudo /etc/init.d/redis-server start 启动6380的redis服务器，设置为6379的slave: redis-server --port 6380 $ redis-cli -p 6380 127.0.0.1:6380> slaveof 127.0.0.1 6379 OK 启动6381的redis服务器，设置为6379的salve redis-server --port 6381 $ redis-cli -p 6381 127.0.0.1:6381> slaveof 127.0.0.1 6379
3) 配置sentinel哨兵
首先新建 sentinel.conf 文件，并对其进行配置，如下所示：
port 26379 Sentinel monitor biancheng 127.0.0.1 6379 1
配置文件说明如下：
port 26379 #sentinel监听端口，默认是26379，可以更改 sentinel monitor
第二个配置项表示：让 sentinel 去监控一个地址为 ip:port 的主服务器，这里的 master-name 可以自定义;
4) 启动sentienl哨兵
方式一: redis-sentinel sentinel.conf 方式二: redis-server sentinel.conf --sentinel
5) 停止主服务器服务
下面模拟主服务意外宕机的情况，首先直接将主服务器的 Redis 服务终止，然后查看从服务器是否被提升为了主服务器。执行以下命令：
#终止master的redis服务 sudo /etc/init.d/redis-server stop
执行完上述命令，您会发现 6381 称为了新的 master，而其余节点变成了它的从机，执行命令验证：
127.0.0.1:6381> set webname www.biancheng.net OK
哨兵的配置文件 sentinel.conf 也发生了变化：
#port 26379 #sentinel myid 4c626b6ff25dca5e757afdae2bd26a881a61a2b2 # Generated by CONFIG REWRITE dir "/home/biancheng" maxclients 4064 sentinel myid 4c626b6ff25dca5e757afdae2bd26a881a61a2b2 sentinel monitor biancheng 127.0.0.1 6379 1 sentinel config-epoch biancheng 2 sentinel leader-epoch biancheng 2 sentinel known-slave biancheng 127.0.0.1 6379 sentinel known-slave biancheng 127.0.0.1 6380 sentinel known-slave biancheng 127.0.0.1 6381 port 26379 sentinel current-epoch 2
如果您想开启多个哨兵，只需配置要多个 sentinel.conf 文件即可，一个配置文件开启一个。
redis的哨兵模式原理是什么?
哨兵模式是一种特殊的模式，Redis 为其提供了专属的哨兵命令，它是一个独立的进程，能够独立运行。下面使用 Sentinel 搭建 Redis 集群，基本结构图如下所示：
在上图过程中，哨兵主要有两个重要作用：
第一：哨兵节点会以每秒一次的频率对每个 Redis 节点发送PING命令，并通过 Redis 节点的回复来判断其运行状态。
第二：当哨兵监测到主服务器发生故障时，会自动在从节点中选择一台将机器，并其提升为主服务器，然后使用 PubSub 发布订阅模式，通知其他的从节点，修改配置文件，跟随新的主服务器。
在实际生产情况中，Redis Sentinel 是集群的高可用的保障，为避免 Sentinel 发生意外，它一般是由 3～5 个节点组成，这样就算挂了个别节点，该集群仍然可以正常运转。其结构图如下所示：
上图所示，多个哨兵之间也存在互相监控，这就形成了多哨兵模式，现在对该模式的工作过程进行讲解，介绍如下：
1) 主观下线
主观下线，适用于主服务器和从服务器。如果在规定的时间内(配置参数：down-after-milliseconds)，Sentinel 节点没有收到目标服务器的有效回复，则判定该服务器为“主观下线”。比如 Sentinel1 向主服务发送了PING命令，在规定时间内没收到主服务器PONG回复，则 Sentinel1 判定主服务器为“主观下线”。
2) 客观下线
客观下线，只适用于主服务器。 Sentinel1 发现主服务器出现了故障，它会通过相应的命令，询问其它 Sentinel 节点对主服务器的状态判断。如果超过半数以上的 Sentinel 节点认为主服务器 down 掉，则 Sentinel1 节点判定主服务为“客观下线”。
3) 投票选举
投票选举，所有 Sentinel 节点会通过投票机制，按照谁发现谁去处理的原则，选举 Sentinel1 为领头节点去做 Failover(故障转移)操作。Sentinel1 节点则按照一定的规则在所有从节点中选择一个最优的作为主服务器，然后通过发布订功能通知其余的从节点(slave)更改配置文件，跟随新上任的主服务器(master)。至此就完成了主从切换的操作。
总之Redis 官方推荐一种高可用方案，它弥补了主从模式的不足，并且能够保证系统的可用性，使开发正常进行!最后大家如果想要了解更多java架构师知识，敬请关注奇Q工具网。
推荐阅读：