Redis 哨兵模式
主从切换技术的方法是：当主服务器宕机了，需要手动将一台从服务器切换为主服务器，这就需要人工干预，这可能会造成一段时间的服务不可用。
一.哨兵模式的概述：
哨兵是一个独立的进程，作为一个进程，他会独立地运行。使用一个或者多个哨兵（sentinel）实例构成的系统可以对Redis节点进行监控，在主节点出现故障的情况下，能将从节点中的一个升级为主节点，进行故障转移，保证数据的一致性。
首先来配置一个主从分离：
一、配置Master
1、修改端口
port 6379
redis 的默认端口是6379
2、修改pidfile
pidfile /var/run/redis_6379.pid
pidfile 是我们启动redis 的时候，linux 为我们分配的一个pid 进程号，如果这里不作修改，会影响后面redis服务的启动
3、启动 redis
启动redis，我们可以看到，redis已经占领了6379端口
进入客户端
有密码的话需要>auth password 输入密码
…
我们可以看到，redis现在的角色是一个master启动的服务。并且默认没有连接从库。
二、配置Slave
和上面配置 master一样，我们需要修改端口号和pid 文件，在修改完之后，我们有两种方法配置从服务
1、在配置文件中配置从服务
# slaveof<masterip> <masterport>
slaveof 10.129.28.149 6379
我们可以在配置文件中直接修改 slaveof 属性，我们直接配置主服务器的ip 地址，和端口号，如果这里主服务器有配置密码
可以通过配置masterauth 来设置链接密码
# masterauth<master-password>
Master auth redis007
启动redis 服务
我们可以看到，现在有两个现在在运行，我们进入7000的客户端，看一下他的状态info，
我们可以看到，现在的redis 是一个从服务的角色，连接着6379的服务。
2、在服务启动后配置
启动7001服务
进入客户端，查看当前服务器的状态并修改：
10.192.28.149:7001> slaveof127.0.0.16379
3、总结
我们先看一下目前master 的状态：
我们可以可以看到，两个从服务已经在连着主服务器，上面两种配置的区别在于，当salve 断线重连之后，
如果我们是修改类配置文件，重连之后会自己链接上去master，并且同步master 上面的数据，
如果我们是手动连接上去的主服务器，重连之后，从服务器会读取自己本地的 rdb 回复数据，而不会去自动链接主服
我们如果需要设置读写分离，只需要在主服务器中设置：
slave-read-only yes
三、Sentinel 哨兵
1、配置端口
在sentinel.conf 配置文件中， 我们可以找到port 属性，这里是用来设置sentinel 的端口，一般情况下，至少会需要三个哨兵对redis 进行监控，我们可以通过修改端口启动多个sentinel 服务。
port 26379
2、配置主服务器的ip 和端口
我们把监听的端口修改成6379，并且加上权值为2，这里的权值，是用来计算我们需要将哪一台服务器升级升主服务器，如果redis实例有密码的话需要加上auth-pass项，否则连接会报失败。
sentinel monitor mymaster 10.129.28.149 6379 2
sentinel auth-pass mymaster redis007
3、启动Sentinel
当我们把其中一个从服务器slave-7001关闭之后，我们可以看到日志显示+sdownslave;
我们再把slave-7001接回去，日志显示+rebootslave 和 –sdown slave。
4、关闭Master
我们手动关闭Master 之后，sentinel在监听master 确实是断线了之后，将会开始计算权值，然后重新分配主服务器
我们可以看到，6379主服务器断了之后，sentinel 帮我们选了7001作为新的主服务器
我们进到7001的客户端，查看他的状态：
我们再进入sentinel的客户端看下：
5、重连Master
大家可能会好奇，如果master 重连之后，他会恢复master的身份吗，答案是并不会，而是会成为新的master的slave。因此当master 回来之后，他也只能当个小弟
我们看下重新连接以后的6379状态：
再看下sentinel中日志：
四、哨兵们是怎么感知整个系统中的所有节点(主节点/从节点/哨兵节点)的
1.首先主节点的信息是配置在哨兵(Sentinel)的配置文件sentinel.conf中,配置 sentinel monitor <master-name> <ip> <redis-port> <quorum>，详见Redis sentinel.conf配置文件详解 2.哨兵节点会和配置的主节点建立起两条连接命令连接和订阅连接
3.哨兵会通过命令连接每10s发送一次INFO命令，通过INFO命令，主节点会返回自己的run_id和自己的从节点信息 4.哨兵会对这些从节点也建立两条连接命令连接和订阅连接 5.哨兵通过命令连接向从节点发送INFO命令，获取到他的一些信息 a. run_id b. role c. 从服务器的复制偏移量 offset 五、哨兵模式下的故障迁移：
1.每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他Sentinel实例发送一个PING命令
2.如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel 标记为主观下线。
3.如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4.当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
5.在一般情况下， 每个 Sentinel 会以每10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令，当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
6.若没有足够数量的 Sentinel 同意Master 已经下线， Master 的客观下线状态就会被移除。 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
原文链接：https://blog.csdn.net/yaooch/article/details/80167571
原文链接：https://www.jianshu.com/p/d6d2325a5ec7
