redis哨兵模式

哨兵模式它是基于主从复制的基础之上进行的

为什么会有哨兵模式的出现？

因为在生产环境中当主机宕机的时候就可以自动的调整redis服务器之间的主从关系话可以时刻的监控每台redis服务器的状态

明明可以用手动调整主从关系为什么还要有哨兵模式呢？

因为在生产环境中如何通过手动调整第一点要花费的时间很长而且具有误错性第二点：它在一定的时间内可能会导致一些问题的产生

哨兵模式它时独立的进程独立运行  它的基本工作流程：哨兵监控多个redis实例并且发送命令给redis服务器等待redis服务器的响应

哨兵的主要功能是：监控，选主，通知

哨兵的架构图：

这里哨兵有两个作用：

1.监控：监控多台redis实例通过发送命令来进行监控

2.如果当主机宕机了则哨兵会通过发布和订阅来通知其他从机进行投票选举主机

那哨兵宕机了呢该怎么办？

一般在生产环境中会设置多个哨兵进行互相监控   

它的基本架构图

原理：

当master宕机了哨兵1发送命令给master发现它没有回应则哨兵1判断它为主观下线（仅仅只有哨兵1判断）当后面的哨兵都发送命令给master发现它没有回应则正式断定master宕机 当哨兵达到一定值的时候则会通过发布和订阅通知其他从机进行投票选举主机这个过程就叫客观下线

操作：

环境：4台redis服务器  （三台搭建主从复制  一主二从    主机：6379  从机：6380 和6381） 一台搭建哨兵

在redis服务器的启动目录中创建sentinel.conf文件

在里写入这段代码

  sentinel   monitor(监控)    myredis（主机的名字随意）   127.0.0.1（本机IP）   6379（主机端口）   1  （当主机宕机了则进行投票选举）

  注意：这是哨兵的配置文件不能写错

 重启哨兵的配置文件

 redis-sentinel    /usr/local/src/redis/config/sentinel.conf

此时正监控主机

模拟宕机情况：

当主机宕机时

哨兵不断地进行发送命令给6379主机

最终自动的选举出新的主机

测试：（当6379主机故障修复时它会怎么办）

在手动配置的时候如果主机故障修复恢复了则它依旧是一台主机 但是没有附属的从机

但是在哨兵模式下如果原主机故障修复了它就会自动的成为先主机的从机

优点：

1.从手动调整到自动调整主从关系，更加的节省了时间

2.哨兵模式是基于主从复制，主从复制的优点它基本上都具备

3.哨兵模式它可以自由的切换主从关系，故障转移，高可用

缺点：

1.哨兵模式的配置繁琐

2.redis是不好扩容的一旦reids集群的容量达到上限则在线扩容就十分麻烦

3.当主节点宕机的时候哨兵模式会出现一个访问瞬断的现象

4..哨兵模式只有一个主节点提供对外服务所以没办法支持高并发，而且主节点的内存不宜设置的太大因为当主节点的内存过大时会导致持久化文件内存过大从而影响数据恢复和主从同步的效率

注意：主节点的内存不能设置太大否则会导致持久化文件过大从而影响到数据恢复和数据同步