系列文章
我们为什么需要哨兵模式？
在主从复制章节的缺点中，我提到主从复制在服务宕机后，需要人工介入设置新的主节点，这显然很不方便，而且如果是半夜服务挂了可能人不能即时的介入，等待时间也会很久。为了解决这个问题，Redis就提供了哨兵模式。
哨兵模式是什么？
哨兵模式就是在主从模式的基础上加上哨兵这个概念，哨兵的作用就是判断这些数据节点是否还能提供服务。如果不能提供服务就将这些节点剔除出集群，如果主节点宕机，哨兵将自动推举新的主节点上任。也就是常说的自动故障转移（Automatic failover）。
哨兵模式示意图
哨兵模式到底实现了那些功能呢？
这里引用Redis官方文档的描述
- 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
- 自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
- 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
- 通知（Notification）：哨兵可以将故障转移的结果发送给客户端。
需要注意：
- 哨兵是个独立进程，需要单独启动服务。
- 哨兵不仅会监控提供数据的服务，也会监控其他哨兵服务。
哨兵模式的原理？
哨兵集群组建
主库中会有一个__sentinel__:hello的频道，哨兵会发布消息到这个频道中，消息内容为自己的IP，其他哨兵会订阅这个频道，收到发布的消息后，会通过消息，建立哨兵集群。
哨兵获取从库
哨兵会向主库发送INFO命令，主库会返回Slave列表，哨兵会通过列表逐个与从库建立连接。
如何判断节点下线
我们需要搞懂两个概念：
- 主观下线：每个哨兵都会定时的监测所有节点，在节点没有做出回应时，这个哨兵就会主观的认为此节点已然下线。但主观线下的判定很多时候是可能造成误差的，比如网络波动等因素，没能及时回应。
- 客观下线：为避免主观带来的误差，所以需要多个哨兵对这个节点是否下线做出自己的主观判断，然后哨兵们投票，如果票数大于等于哨兵配置文件中的
quorum配置项，我们就认为他确实是下线了，是客观存在的事实。
主库下线重选
主库如果被客观判定下线后，哨兵就需要有个新的节点替代原来主库的位置，这时哨兵们就会开始选举新的主库。
新的主库需要逐步筛选以下三个条件：
- 是健康的（没有下线或断线）。
-
salve-priority从节点优先级最高的（redis.conf）。 - 复制偏移量最大的。
哨兵选举故障转移执行节点
为什么需要选举？
哨兵一般为集群化运行，但不可能这些节点同时做故障转移这件事，这时就需要通过内部选举选择一个执行节点。
具体怎么做？
哨兵的选举机制其实很简单，就是一个Raft选举算法： 选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举。
任何一个想成为 Leader 的哨兵，要满足两个条件：
- 拿到半数以上的赞成票。
- 拿到的票数同时还需要大于等于哨兵配置文件中的
quorum值。
故障转移
故障转移分以下几步：
- 将新选出的主节点解除从节点身份，升级为主节点。
- 将所有其他从节点指向新的主节点。
- 取消原有主节点身份，降格为从节点并指向新的主节点（就算此节点重启复活也还是从节点）。
- 通知应用程序新节点地址。
哨兵模式的优势？
- 哨兵模式是基于主从模式建立的，所以主从模式有的优点我们都有。
- 哨兵模式解决了主从模式宕机需要人工介入才能恢复使用的问题。
哨兵模式的缺点？
- 哨兵模式是为了解决我提到的主从复制缺点中的第一条而出现的，也就是说除了第一条。其他的缺点哨兵模式也依旧存在。
- 主从模式在最低的情况下，两台服务器即可，而哨兵模式最少需要三台服务来保证选举投票制度的多数，并且保证有可转移的目标。也就是说相对主从，他需要更多的服务器，也需要相对更高的计算机性能。
