Redis哨兵模式搭建

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提供服务。