redis的哨兵机制

什么是哨兵机制?

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。
每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。
虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。

哨兵(sentinel) 的一些设计思路和zookeeper非常类似
为了达到redis的高可用，有两种部署方式：
1. 主从复制+哨兵机制
2. 集群模式
哨兵机制是从redis 2.8开始支持。集群模式是从redis 3.0开始支持。

主从复制的意义：
主从复制可以把主节点的数据复制给从节点。从节点可以备份主节点的数据，起到主节点down调，顶上来接替主节点工作的作用。也可以起到分担主节点读压力的作用。

没有哨兵机制的时候，主从复制结构部署存在的问题是什么？也可以说redis主节点发生故障如何解决

如果主节点down调，主从切换需要人工介入。

主从切换步骤为：
1.启用从节点为主节点。命令：slaveof no one
2.旧主节点的其他从节点变成新主节点的从节点。命令：slaveof new master
3.通知应用方redis主节点变成了新主节点。修改客户端调用的地址并重启客户端。
4.旧主节点变成新主节点的从节点。命令：slaveof new master
哨兵机制存在的意义：
为了实现redis故障转移的自动化。自动发现，自动转移。不需要人工参与。
哨兵机制是怎样的部署结构？

redis的哨兵机制
主从复制节点是数据节点，哨兵机制部署的节点是监控节点，它们都是redis实例。但是哨兵节点不存储数据，它们监控主从数据节点的状态，若哨兵判定主节点down掉后，就会自动执行上边提到的手工操作的4小步骤。

哨兵节点自动化完成故障转移的过程：

哨兵机制是怎样判断主节点down调的？

哨兵机制是建立了多个哨兵节点，它们共同监控数据节点的运行状况。同时哨兵节点之间也互相通信。交换对主从节点的监控状况。下面提到两个概念：
主观下线和客观下线: 一个哨兵节点判定主节点down掉是主观下线。只有半数个哨兵节点都主观判定主节点down掉，此时多个哨兵节点交换主观判定结果，才会判定主节点客观下线。
基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制，每个哨兵都投自己为领导者。最终被投为领导者的哨兵节点完成主从自动化切换的过程。当判断为主观下线时，不会进行主从切换过程。

redis的哨兵机制