主从复制完成后，无法实现主从的替换，需要引入redis的哨兵技术。
redis的哨兵逻辑
单独启动哨兵的进程，监听某一个主从的结构，单独连接主节点，利用info命令查看主从状态
rpc心跳（heartbeat）机制检测主节点的存活；
哨兵集群会对当前监听的主从节构中出现的事故进行过半选举的投票；
例如主节点的宕机会通过哨兵集群进行过半选举，从从节点中选出一个来接替称为主节点。
哨兵（sentinel）监听的结构图
哨兵的安装与测试
1、修改启动哨兵的配置文件
在redis根目录的一个sentinel.conf（里面配置了主从关系，主节点信息）
通过：redis-sentinel sentinel.conf 启动哨兵（这里先不启动）
需要注释掉bind ，不需要绑定
protected-mode no 取消注释，配置为no
配置端口（23680,26381）
sentinel monitor mymaster 127.0.0.1 6379 2
修改监听主从的挂接配置
sentinel monitor：开始监听主从结构中的主节点；
mymaster：监听当前主从结构的代号（自定义）
ip：主节点所在的ip（使用对外能往返的主节点ip）
如果哨兵和主从节点在同一个机器，不要使用127.0.0.1，会造成代码访问失效；
port：主节点端口号；
2：主观下限票数（最少最少启动的监听主从结构的哨兵个数）
哨兵集群某个节点也有宕机可能，一旦宕机会造成集群投票情况的变化，
为了防止宕机过多最终导致整个哨兵的投票不可信（1个节点的投票不可信）
选举新主节点失败时的时间延迟(第二轮选举和第一轮选举的时间间隔)
失败重新选举
sentinel failover-timeout mymaster 10000（10s）
当前哨兵集群对某一个事件的选举如果不成立，将会根据这里的配置毫秒数进行新的选举
直到选举成功为止。
同理配置第二 、第三个哨兵。
2、启动哨兵进程，开启监听主从结构
#redis-sentinel 配置文件名
3、测试
a、kill掉主节点，哨兵能否高可用
6383被选举为主节点
b、将宕机的主节点重启
启动后发现哨兵将重启的主节点转化成从节点提供主从服务
c、宕机掉一个哨兵
当两个哨兵管理主从时,一个宕机,导致另一个的选举没有过半无法生效
quorum
最好启动奇数个哨兵,每次至少有过半的哨兵选举成功才行
4、重启哨兵集群步骤
a、先启动三个主从节点
b、检查主从关系
分别登陆3个客户端，使用info replication查看主从关系
c、查看setinel配置文件
如果和当前重新建立的主从结构一致，直接启动哨兵
如果端口和和主从不一致，将端口修改后，把最后的配置内容删除
d、启动哨兵
redis-sentinel 哨兵配置文件
