redis哨兵的搭建建立在已经存在的主从集群之上，因此你需要先搭建好一套redis主从集群，这里我们使用三个节点，即一主两从。
主节点ip地址：192.168.50.130
第一个从节点ip地址：192.168.50.131
第二个从节点ip地址：192.168.50.132
1、主从搭建
主节点配置文件添加一行配置masterauth "111111"
从节点配置文件添加如下配置
replicaof 192.168.50.130 6379
masterauth "111111"
注意：masterauth是主从之间连接的密码，节点的密码都是一样的，此外这个密码与requirepass不是一回事。
搭建好之后启动一下redis。
在主节点上面，进入redis命令行执行info replication命令，可以看到如下信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.50.131,port=6379,state=online,offset=1109,lag=0
slave1:ip=192.168.50.132,port=6379,state=online,offset=1109,lag=0
master_replid:d1fb20462e09464a4b27400aa04c68de22663197
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1109
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1109
从上面可以看到从节点的信息，以及当前节点确实是master节点。
现在我们来从节点看看，进入redis命令行执行info命令。
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.50.130
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:1305
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:d1fb20462e09464a4b27400aa04c68de22663197
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1305
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1305
我们能够看到上面的master_link_status为up状态，说明当前节点是正常的。第二个从节点可以自己做验证。
那么验证主从集群是否可用，我们可以在主节点上面创建一个key和value，然后此时去两个从节点分别查看是否同步对应的key和value数据即可。
2、哨兵搭建
上面的主从搭建好之后，此时我们就可以来搭建哨兵模式了。简单的介绍一下哨兵集群。
Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。
虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器， 你可以在启动一个普通 Redis 服务器时通过给定 –sentinel 选项来启动 Redis Sentinel
首先是把哨兵的配置文件sentinel.conf复制到/apps/redis/etc目录下，这个目录是我们编译redis的工作目录。三个节点都需要把配置文件放到etc目录下面。我们在主节点上面配置好sentinel.conf配置文件，然后再复制该文件到另外两个节点上面去。
bind 0.0.0.0
port 26379
daemonize yes
pidfile "redis-sentinel.pid"
logfile "sentinel.log"
dir "/apps/redis/logs"
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.50.130 6379 2
sentinel down-after-milliseconds mymaster 15000
sentinel auth-pass mymaster 111111
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
简单讲解一下上面的配置：
sentinel monitor mymaster 192.168.50.130 6379 2 #法定人数限制(quorum)，即有几个slave认为master down了就进行故障转移
sentinel auth-pass mymaster 111111 # 这个是密码，密码需要与requirepass密码保持一直。
sentinel down-after-milliseconds mymaster 30000 #(SDOWN)主观下线的时间
sentinel parallel-syncs mymaster 1 #发生故障转移时候同时向新master同步数据的slave数量，数字越小总 同步时间越长
sentinel failover-timeout mymaster 180000 #所有slaves指向新的master所需的超时时间
sentinel deny-scripts-reconfig yes #禁止修改脚本
复制该配置文件到另外的两个节点上面
[root@lvs etc]# scp sentinel.conf root@192.168.50.132:/apps/redis/etc/
root@192.168.50.132's password:
sentinel.conf 100% 9814 6.8MB/s 00:00
三台主机都启动哨兵服务
redis-sentinel /apps/redis/etc/sentinel.conf
首先在主节点查看哨兵服务
[root@lvs etc]# redis-cli -p 26379 # 这里需要指定连接的是26379这个哨兵服务端口
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.50.130:6379,slaves=2,sentinels=3
显示为ok状态，说明这是没有问题的。
再去其他的节点上看看哨兵服务是否正常。
[root@nginx-web1 etc]# redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.50.130:6379,slaves=2,sentinels=3
第三个节点
[root@nginx-web2 etc]# redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.50.130:6379,slaves=2,sentinels=3
看的出来几个节点的哨兵服务都是正常的，然后现在我们看看主节点的哨兵日志，。
1879:X 07 Oct 2020 12:10:51.186 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1879:X 07 Oct 2020 12:10:51.186 # Redis version=5.0.9, bits=64, commit=00000000, modified=0, pid=1879, just started
1879:X 07 Oct 2020 12:10:51.186 # Configuration loaded
1880:X 07 Oct 2020 12:10:51.187 * Increased maximum number of open files to 10032 (it was originally set to 1024).
1880:X 07 Oct 2020 12:10:51.188 * Running mode=sentinel, port=26379.
1880:X 07 Oct 2020 12:10:51.190 # Sentinel ID is cdc81e010e3676379c065b3ea78c56a5ef761732
1880:X 07 Oct 2020 12:10:51.190 # +monitor master mymaster 192.168.50.130 6379 quorum 2
1880:X 07 Oct 2020 12:10:51.191 * +slave slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:10:51.192 * +slave slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:10:59.067 * +sentinel sentinel af707d062b0d449873e864005c1a308cbc2e48e4 192.168.50.131 26379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:11:02.859 * +sentinel sentinel c4ba9fcb2a9d7dd835b37588a0238fb8c937109e 192.168.50.132 26379 @ mymaster 192.168.50.130 6379
从上面可以看出来，当前节点是主节点并已经被监控到，此外最后四行也检测到了两个从节点。整个哨兵集群是没有问题的。
3、测试哨兵集群是否可正常切换
现在我们把主节点的redis服务给停止掉
systemctl stop redis
稍等片刻，大约15秒左右，开始进行故障转移。
现在我们随便连接到一个从节点上面，比如第二个节点192.168.50.132这个上面
[root@nginx-web2 etc]# redis-cli -a 111111
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.50.131
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:117783
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2f77718643d6b61adf730445575f16bb02a2714d
master_replid2:d1fb20462e09464a4b27400aa04c68de22663197
master_repl_offset:117783
second_repl_offset:95013
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:141
repl_backlog_histlen:117643
通过上面的可以看到，当前这个从节点依然是从节点，但是主节点发生了变化，现在主节点是192.168.50.131这个节点了，而且是up状态，即当前节点是正常的。
那么现在我们来到192.168.50.131这个节点上面，查看集群状态
[root@nginx-web1 etc]# redis-cli -a 111111
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.50.132,port=6379,state=online,offset=139945,lag=0
master_replid:2f77718643d6b61adf730445575f16bb02a2714d
master_replid2:d1fb20462e09464a4b27400aa04c68de22663197
master_repl_offset:139945
second_repl_offset:95013
看得出来集群角色已经由slave转变为了master角色。此时这台节点对外提供服务。
我们通过日志也是可以从日志判断出集群的变化的，比如现在我们打开原来旧的master节点（192.168.50.130）的哨兵日志sentinel.log，查看一下
1880:X 07 Oct 2020 12:18:28.483 # +sdown master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.567 # +odown master mymaster 192.168.50.130 6379 #quorum 3/2
1880:X 07 Oct 2020 12:18:28.567 # +new-epoch 2
1880:X 07 Oct 2020 12:18:28.567 # +try-failover master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.571 # +vote-for-leader cdc81e010e3676379c065b3ea78c56a5ef761732 2
1880:X 07 Oct 2020 12:18:28.576 # c4ba9fcb2a9d7dd835b37588a0238fb8c937109e voted for cdc81e010e3676379c065b3ea78c56a5ef761732 2
1880:X 07 Oct 2020 12:18:28.576 # af707d062b0d449873e864005c1a308cbc2e48e4 voted for cdc81e010e3676379c065b3ea78c56a5ef761732 2
1880:X 07 Oct 2020 12:18:28.662 # +elected-leader master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.662 # +failover-state-select-slave master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.718 # +selected-slave slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.718 * +failover-state-send-slaveof-noone slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:28.784 * +failover-state-wait-promotion slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:29.084 # +promoted-slave slave 192.168.50.131:6379 192.168.50.131 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:29.084 # +failover-state-reconf-slaves master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:29.157 * +slave-reconf-sent slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:29.708 # -odown master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:30.137 * +slave-reconf-inprog slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:30.138 * +slave-reconf-done slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:30.195 # +failover-end master mymaster 192.168.50.130 6379
1880:X 07 Oct 2020 12:18:30.195 # +switch-master mymaster 192.168.50.130 6379 192.168.50.131 6379
1880:X 07 Oct 2020 12:18:30.195 * +slave slave 192.168.50.132:6379 192.168.50.132 6379 @ mymaster 192.168.50.131 6379
1880:X 07 Oct 2020 12:18:30.196 * +slave slave 192.168.50.130:6379 192.168.50.130 6379 @ mymaster 192.168.50.131 6379
1880:X 07 Oct 2020 12:18:45.200 # +sdown slave 192.168.50.130:6379 192.168.50.130 6379 @ mymaster 192.168.50.131 6379
这里我们解释一下上面的日志大概的含义
+reset-master ：主服务器已被重置。
+slave ：一个新的从服务器已经被 Sentinel 识别并关联。
+failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。
+failover-detected ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
+slave-reconf-sent ：领头（leader）的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令，为实例设置新的主服务器。
+slave-reconf-inprog ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
+slave-reconf-done ：从服务器已经成功完成对新主服务器的同步。
-dup-sentinel ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。
+sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
+sdown ：给定的实例现在处于主观下线状态。
-sdown ：给定的实例已经不再处于主观下线状态。
+odown ：给定的实例现在处于客观下线状态。
-odown ：给定的实例已经不再处于客观下线状态。
+new-epoch ：当前的纪元（epoch）已经被更新。
+try-failover ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。
+elected-leader ：赢得指定纪元的选举，可以进行故障迁移操作了。
+failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
selected-slave ：Sentinel 顺利找到适合进行升级的从服务器。
failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
failover-end-for-timeout ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
+switch-master ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。