哨兵也是一个单独的redis进程，它不对外提供服务，主要是用来监控主数据库和从数据库的运行情况，然后在主数据库出现故障时，主动的把从数据库升级为主数据库，避免了人工切换的操作。
先启动一个redis实例，端口为6379，作为主数据库，然后通过以下两个命令再启动两个redis服务，端口分别是6380，6381，同时把它们指定为6379端口redis服务的从数据库：
redis-server /usr/local/etc/redis.conf --port 6380 --slaveof 127.0.0.1 6379
redis-server /usr/local/etc/redis.conf --port 6381 --slaveof 127.0.0.1 6379
此时查看下端口为6379的主数据库的replication信息：
可以发现此时主数据库有两个从库，端口分别为6380，6381。
接下来配置下哨兵，创建一个配置文件，名为sentinel.conf，该文件的内容为：
# 配置监听的主服务器
sentinel monitor masterone 127.0.0.1 6379 1
sentinel monitor 表示哨兵监控
masterone表示自己要监控的主数据库的名字，可以自定义。不过这个名字必须只能由大小写字母、数字和“.-_”这 3 个字符组成。
127.0.0.1 6379表示要监控服务的ip地址和端口号。
1表示最低通过票数，代表只有1个或1个以上的哨兵认为主数据库主观下线的时候，才会进行故障切换（failover）操作。
如下：
使用命令redis-sentinel +哨兵配置文件的地址 启动哨兵服务，如下：
输出如下信息：
1表示哨兵进程的运行id
2表示哨兵经常监控的主数据库
3，4表示哨兵已经自动发现了它监控的主数据库下的两个从数据库
接着关闭端口为6379的主数据库，如下：
等待一段时间，默认是30秒，哨兵会出现如下结果：
1的+sdown表示sentinel主观上的认为6379端口的服务已经停止了，这是sentinel自己作出的判断。
2的+odown表示sentinel客观上的认为6379端口的服务已经停止了，不过客观下线是需要一定数量的sentinel达成一致意见才能认为一个master已经停止了服务，由于此时只有一个sentinel，所以也做了客观下线。
3表示达到了failover条件，要开始执行故障恢复，等待其他sentinel的选举，挑选出一个从数据库，将其升格为主数据库。
4表示故障恢复完成。
5表示从数据库127.0.0.1:6380被升格为了主数据库。
6，7表示新的主数据库有两个从库，分别为127.0.0.1:6379 ，127.0.0.1:6381，此时127.0.0.1:6379 服务虽然已经断开，但是哨兵并没有清除该无效实例，是为了实例恢复后，方便重新加入时以从数据库的身份继续服务。
8表示发现127.0.0.1:6379服务已经宕机，等待恢复。
此时查看端口为6380的服务的replication信息，如下：
可以发现此时6380端口的服务是主数据库，有一个连接的从库，是端口为6381的redis服务。
此时重启6379服务，看下哨兵输出结果：
看输出结果能知道端口号为6379的redis实例已经恢复服务了。
然后再看下此时作为主数据库的端口号为6380实例的replication信息，如下：
发现端口号为6379的redis实例恢复服务后，被设置为端口号为6380服务实例的从数据库了。
最后看看端口号为6379的redis实例的replication信息，如下：
可以看到此时端口号为6379的redis实例的角色已经是从数据库，而且它的主数据库正是端口号为6380服务实例。