为什么要引入Redis 哨兵机制呢
Redis主从复制中存在问题，第一个问题：当主节点挂了 的 时候，从节点转化 为主节点 必须要人工转化
第二个 问题 ：主节点写数据 的压力并没有被分担 当写请求过多，主节点仍承受巨大压力
引入哨兵机制就是为了 解决第一个问题
名词解释
主节点：一个Redis -server进程
从节点：一个Redis-server进程
Redis数据节点：主从节点
哨兵节点：一个Redis-sentinel进程（它与主从节点不同，是Redis的不同进程）用来监测主从节点
哨兵集合：主要是防止哨兵节点挂 所以引入多个哨兵结合组成集合
Redis sentinel架构如下
这些sentinel节点会与主从节点建立长的TCP连接 定时发送心跳包 来监控该节点
1.设计sentinel哨兵 节点集合 去监控 主从节点
2.当有sentinel某一节点 监控到主节点 挂了 它会与其他sentinel节点进行 沟通 查证是否 该主节点是否真正挂掉，防止出现误判的情况
3.发现主节点挂之后，sentinel节点群就会选举出一个leader 这个leader就会从从节点中选择一个作为新的主节点
4.挑选出新的节点后 ，哨兵节点就会控制该节点执行slaveof no one，将其他从节点slave到该节点下
5.哨兵节点就会通知客户端新的主节点是谁，这样客户端后续的操作就针对新的主节点进行操作了
哨兵节点核心功能:
1.监控
2.自动故障转移'
3.通知客户端
注意：哨兵节点有一个也是可以的
但会出现两个问题：
1.当哨兵节点挂时，程序 的问题无法保障
2.误判可能性增加 毕竟网络传输容易出现抖动和延迟
哨兵节点最好是奇数个 建议至少是三个
当 曾经的主节点恢复后 会变为从节点留在新主节点下
主从切换的 具体流程
1.主观下线
哨兵节点监测到主节点挂（可能 出现误判此时）
2.客观下线
哨兵节点集合就会投票 判断是否真的挂掉 （票数达到法定票数）
3.哨兵节点集合 推举出一个 leader
由这个leader去负责选一个从节点来顶替主节点
4.leader 从 从节点集合中选出一个主节点
a）优先级
每个Redis节点 都会在配置文件中，有一个优先级的设置，slave-priority 优先级高的从节点 就会胜出
b）offset 同步进度
offset 从节点从主节点 这边同步数据的进度 ，数值越大，说明此从节点的数据与主节点越接近
c）run_id
每个Redis节点启动的时候随机生成的一串数字 此时随便选一个
5.leader就会控制所选出的从节点
执行slaveof no one 成为主节点 ，其他从节点执行slaveof 加入到新主节点下
注意 哨兵集合是先选举出一个leader 而不是先选出一个从节点 从节点的选择是所选出leader的工作
总结
1.哨兵节点不能只有一个，否则哨兵节点挂了也会影响系统可用性
2.哨兵节点最好是奇数个，方便选举出leader 得票更容易超过半数
3.哨兵节点不负责存储数据，仍然是redis主从节点负责存储
4.哨兵+主从复制 解决的问题是"提高可用性"，不能解决数据 极端情况下丢失的问题（当主节点挂时 从节点还未来得及数据同步 ）
5.哨兵+主从复制不能提高数据的存储容量，当我们 需要存的数据接近或超过机器的物理内存时，这样的结构就难以胜任了