Redis 哨兵模式是建设在主从模式的根底上的，解决的是主实例单机故障问题，通过哨兵零碎能够主动故障转移，切换到新的主实例上。
咱们先来搭建一个由三个 Redis 实例组成的主从集群。
之前咱们讲过应用 utils/install-server.sh 来装置 Redis 服务。咱们应用默认门路将 Redis 装置到 /usr/local/bin 目录下。
搭建主从模式
单机 centos7 环境下启动三个 Redis 服务，端口别离为 6379、6380、6381，将 6379 实例作为主实例。在 /opt 目录下创立 redis 目录寄存配置文件，日志、数据文件等
cd /opt
mkdir redis批改 6379.conf 文件，次要批改如下
# 端口
port 6379
# 数据文件目录
dir /var/lib/redis/6379
# 日志文件
logfile /var/log/redis_6379.log启动 6379 Redis
cd /usr/local/bin
./redis-server /opt/redis/6379.conf同样的 6380 和 6381 的依照 6379 配置，变更端口号即可。但作为 Redis 从服务要指定复制的 redis 主实例，减少如下配置并启动
# 指定 Redis 复制节点
replicaof 127.0.0.1 6379这样一主两从的 Redis 主从模式集群搭建实现了。
哨兵零碎搭建
哨兵零碎用来监控主从集群各个实例的衰弱状况。哨兵零碎也是一个集群零碎，避免哨兵单点故障。
筹备哨兵配置，次要配置如下（剩下的应用默认配置）
# 指定哨兵的端口号（默认 26379）port 26379
# 指定监控的主从集群的 mater 实例 127.0.0.1 6379，# 监控的集群名字 mymaster(能够随便定义名字，保障惟一即可)
# 最初的 2 示意投票权重，个别为哨兵实例总数 /2 + 1
sentinel monitor mymaster 172.0.0.1 6379 2启动哨兵
启动哨兵应用的启动程序和 Redis 服务的启动程序一样，指定不同配置文件和 sentinel 模式就好
./redis-server /opt/redis/26379.conf --sentinel
启动 26379 哨兵实例胜利后，哨兵会生成一个本人的实例 Id，并会通过监控的 master 找到 slave 的地址，将他们保留到 26379.conf 配置文件中。
port 26379
sentinel monitor mymaster 172.18.0.111 6379 2
# Generated by CONFIG REWRITE
protected-mode no
user default on nopass ~* &* +@all
dir "/usr/local/bin"
sentinel myid 8479791aeec61fdef62ff78556e55b07e7e80c0d
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
sentinel current-epoch 0
sentinel known-replica mymaster 172.18.0.111 6381
sentinel known-replica mymaster 172.18.0.111 6380剩下的两个哨兵实例别离应用 26380 和 26381 做为端口，将对应的配置文件的 port 批改即可。
启动完剩下的两个哨兵 26380 和 26381 之后，咱们再看一下 26379 的配置信息，发现文件中追加了 26380 和 26381 这两个哨兵地址信息。这样整个哨兵集群中每个哨兵的地址都保留到了其余哨兵的配置中，进而能够进行互相通信。
sentinel known-sentinel mymaster 172.18.0.111 26380 82bf406747cc2d3322b0df37aa0f31b11f1b070f
sentinel known-sentinel mymaster 172.18.0.111 26381 80c2aa01a7226a7564b2eedfd18e2cb7d6f615d3故障主动转移
咱们强制敞开 6379Redis 服务，期间 26380 被选举为了 sentinel leader，咱们察看一下 26379 哨兵零碎的操作日志
+sdown master mymaster 172.18.0.111 6379
+odown master mymaster 172.18.0.111 6379 #quorum 2/2
+new-epoch 1
+try-failover master mymaster 172.18.0.111 6379
+vote-for-leader 82bf406747cc2d3322b0df37aa0f31b11f1b070f 1
80c2aa01a7226a7564b2eedfd18e2cb7d6f615d3 voted for 82bf406747cc2d3322b0df37aa0f31b11f1b070f 1
8479791aeec61fdef62ff78556e55b07e7e80c0d voted for 82bf406747cc2d3322b0df37aa0f31b11f1b070f 1
+elected-leader master mymaster 172.18.0.111 6379
+failover-state-select-slave master mymaster 172.18.0.111 6379
+selected-slave slave 172.18.0.111:6381 172.18.0.111 6381 @ mymaster 172.18.0.111 6379
+failover-state-send-slaveof-noone slave 172.18.0.111:6381 172.18.0.111 6381 @ mymaster 172.18.0.111 6379
+failover-state-wait-promotion slave 172.18.0.111:6381 172.18.0.111 6381 @ mymaster 172.18.0.111 6379
+promoted-slave slave 172.18.0.111:6381 172.18.0.111 6381 @ mymaster 172.18.0.111 6379
+failover-state-reconf-slaves master mymaster 172.18.0.111 6379
+slave-reconf-sent slave 172.18.0.111:6380 172.18.0.111 6380 @ mymaster 172.18.0.111 6379
+slave-reconf-inprog slave 172.18.0.111:6380 172.18.0.111 6380 @ mymaster 172.18.0.111 6379
+slave-reconf-done slave 172.18.0.111:6380 172.18.0.111 6380 @ mymaster 172.18.0.111 6379
+failover-end master mymaster 172.18.0.111 6379
+switch-master mymaster 172.18.0.111 6379 172.18.0.111 6381
+slave slave 172.18.0.111:6380 172.18.0.111 6380 @ mymaster 172.18.0.111 6381
+slave slave 172.18.0.111:6379 172.18.0.111 6379 @ mymaster 172.18.0.111 6381
+sdown slave 172.18.0.111:6379 172.18.0.111 6379 @ mymaster 172.18.0.111 6381咱们详细描述一下上述转换过程
+sdown master mymaster 172.18.0.111 6379
将 6379 标记为主观下线+odown master mymaster 172.18.0.111 6379 #quorum 2/2
取得其余 sentinel 投票，将 6379 标记为主观下线+try-failover master mymaster 172.18.0.111 6379
尝试对“mymaster”集群进行故障转移+vote-for-leader 82bf406747cc2d3322b0df37aa0f31b11f1b070f 1
80c2aa01a7226a7564b2eedfd18e2cb7d6f615d3 voted for 82bf406747cc2d3322b0df37aa0f31b11f1b070f 1
8479791aeec61fdef62ff78556e55b07e7e80c0d voted for 82bf406747cc2d3322b0df37aa0f31b11f1b070f 1
投票选举 sentinel leader，来执行故障转移操作，统一选举 26479 实例为 sentinel leader+elected-leader master mymaster 172.18.0.111 6379
sentinel leader 选举实现+failover-state-select-slave master mymaster 172.18.0.111 6379
开始在集群中抉择满足条件的 slave 实例，通过各个 sentinel 的投票选举产生新的 master+selected-slave slave 172.18.0.111:6381 172.18.0.111 6381 @ mymaster 172.18.0.111 6379
选举出 6381 Redis 实例+failover-state-send-slaveof-noone slave 172.18.0.111:6381 172.18.0.111 6381 @ mymaster 172.18.0.111 6379
对 6381 Redis 实例执行 noone slave 操作，去除 slave 属性+failover-state-wait-promotion slave 172.18.0.111:6381 172.18.0.111 6381 @ mymaster 172.18.0.111 6379
期待其余 sentinel 投票确认 6381 Redis 实例降级为 master+promoted-slave slave 172.18.0.111:6381 172.18.0.111 6381 @ mymaster 172.18.0.111 6379
sentinel 投票实现，确认抉择 6381 slave+failover-state-reconf-slaves master mymaster 172.18.0.111 6379
开始执行 reconf 操作，批改集群中 slave 的配置+slave-reconf-sent slave 172.18.0.111:6380 172.18.0.111 6380 @ mymaster 172.18.0.111 6379
批改指标 slave 6380 Redis 实例配置，使其追寻新的 master 6381+slave-reconf-inprog slave 172.18.0.111:6380 172.18.0.111 6380 @ mymaster 172.18.0.111 6379
指标 salve 6380 正在执行 salve of 操作，追寻新的 master+slave-reconf-done slave 172.18.0.111:6380 172.18.0.111 6380 @ mymaster 172.18.0.111 6379
指标 slave 6380 执行 slave of 操作实现。如果还存在其余 slave 实例，会继续执行下一个 slave+failover-end master mymaster 172.18.0.111 6379
mymaster 集群整个故障转移实现+switch-master mymaster 172.18.0.111 6379 172.18.0.111 6381
master 实例由 6379 切换到 6381 实现+slave slave 172.18.0.111:6380 172.18.0.111 6380 @ mymaster 172.18.0.111 6381
slave 6380 追寻新的 master 6381 实现+slave slave 172.18.0.111:6379 172.18.0.111 6379 @ mymaster 172.18.0.111 6381
slave 6379 追寻新的 master 6381 实现6379 Redis 被降级为 slave，并追寻到新的 master 6381 上，当从新上线时会做为 6381 的 slave 提供服务。