写在前面
Redis主从模式的主要缺点: 主从模式不具备自动容错和恢复的功能，一旦主数据库，从节点晋升未主数据库的过程需要人为操作，维护的成本就会升高，并且主节点的写能力、存储能力都会受到限制
Redis的哨兵模式其实是升级版的主从模式,其搭建也是基于主从模式的,关于主从模式的搭建,各位靓仔请移步,本文不再赘述Redis 主从结构搭建 保姆级图文教程
哨兵模式系统层面提高了系统的可用性和性能、稳定性。当master宕机的时候，能够自动进行故障恢复，需不要人为的干预
启动主从环境
cd /usr/local/redis/bin
./redis-server /usr/local/redis/6000/redis.conf
./redis-server /usr/local/redis/6001/redis.conf
./redis-server /usr/local/redis/6002/redis.conf
创建哨兵配置文件 sentinel.conf
进入到对应的目录 创建哨兵的配置文件,注意不同服务配置的port端口不同
cd /usr/local/redis/6000
vi sentinel.conf
daemonize yes
# 给master起一个名字mymaster，并且配置master的ip和端口
sentinel myid 58d9029b603bd8a52280a5e43cc05212a44c1876
# master的密码
sentinel deny-scripts-reconfig yes
#另外两个配置36379,46379端口
port 26379
# 3s未回复PING就认为master主观下线
sentinel monitor mymaster 127.0.0.1 6002 1
# 执行故障转移时，最多可以有2个slave实例在同步新的master实例
sentinel down-after-milliseconds mymaster 3000
# 如果在10s内未能完成故障转移操作认为故障转移失败
sentinel failover-timeout mymaster 100000
启动哨兵模式
配置文件完成后,开启哨兵
cd /usr/local/redis/bin
./redis-server /usr/local/redis/6000/sentinel.conf --sentinel
./redis-server /usr/local/redis/6001/sentinel.conf --sentinel
./redis-server /usr/local/redis/6002/sentinel.conf --sentinel
至此哨兵模式已经完整搭建好了
哨兵模式验证
当master宕机的时候，能够自动进行故障恢复，需不要人为的干预,这里我们来动手实验一下
首先正常情况6000主服务,6001,6002从服务器,支持读,不支持写,如图"READONLY You can't write against a read only replica."
现在我们模拟宕机,杀死掉主服务,看下哨兵是否能感知,做master切换
kill -9 26419
观察剩下的之前6001,6002服务,是否有人做了master,redis运行正常
观察到6002做了master,6001还是从服务器写
补充: Redis 选举算法
当master被认为客观下线后，又是怎么进行故障恢复的呢？原来哨兵中首先选举出一个老大哨兵来进行故障恢复，选举老大哨兵的算法叫做**「Raft算法」**：
1.发现master下线的哨兵（sentinelA）会向其它的哨兵发送命令进行拉票，要求选择自己为哨兵大佬。
2.若是目标哨兵没有选择其它的哨兵，就会选择该哨兵（sentinelA）为大佬。
3.若是选择sentinelA的哨兵超过半数（半数原则），该大佬非sentinelA莫属。
4.如果有多个哨兵同时竞选，并且可能存在票数一致的情况，就会等待下次的一个随机时间再次发起竞选请求，进行新的一轮投票，直到大佬被选出来。
选出大佬哨兵后，大佬哨兵就会对故障进行自动回复，从slave中选出一名slave作为主数据库，选举的规则如下所示：
1.所有的slave中`slave-priority`优先级最高的会被选中。
2.若是优先级相同，会选择偏移量最大的，因为偏移量记录着数据的复制的增量，越大表示数据越完整。
3.若是以上两者都相同，选择ID最小的。
通过以上的层层筛选最终实现故障恢复，当选的slave晋升为master，其它的slave会向新的master复制数据，若是down掉的master重新上线，会被当作slave角色运行。
