一.主库挂了，如何不间断服务？

主库挂了，需要运行一个新的主库：将从库切换为主库。这就涉及到三个问题：

主库真的挂了吗？

选择哪个从库作为主库？

如何把新主库相关信息通知给从库和客户端

Redis主从集群中，哨兵是实现主从库自动切换的关键机制，有效解决主从复制模式下故障转移的上面这些问题。

二.哨兵机制的基本流程

哨兵是一个运行在特殊模式下的Redis进程，主从库实例运行时，他也在运行。

哨兵负责三个任务：监控，选主（选择主库）和通知。

监控

监控是指哨兵进程运行时，周期性给所有主从库发送PING命令，检测他们是否仍然在线运行。

从库没有在规定时间内响应哨兵的PING命令，哨兵就会把它标记为"下线状态"；

主库没有在规定时间呢响应哨兵的PING命令，哨兵就会判定主库下线启动选主流程。

选主

哨兵在主库挂了以后，按照一定规则从从库中选出作为新的主库。

通知

通知：哨兵将选出的新主库连接信息发给其他从库，让他们执行replicaof命令，和新主库建立连接，复制数据。同时，哨兵会把新主库的连接信息通知给客户端，让它们将操作请求发送给新主库上。

通知任务简单，哨兵只需要把新主库信息发给从库和客户端。通知他们和新主库建立连接就成，不涉及决策逻辑。

监控和选主需要哨兵做出决策：

监控任务哨兵需要判断主库是否处于下线状态；

选主任务哨兵决定选主哪个从库实例作为主库。

二.主管下线和客观下线

哨兵进程会使用PING命令检测主和从库的连接情况，用来判断实例状态；

如果哨兵发现主库或者从库对PING命令响应超时，那么哨兵就会把它标记为"主观下线"。

从库，哨兵可以简单标记为"主观下线"，因为从库下线影响不大，集群对外服务不会中断。

主库，哨兵不能简单标记为"主观下线"，开启主从切换。因为可能存在一种情况：哨兵误判，主库没有故障，可是一旦启动选主和通知操作后续的选主和通知操作都会带来额外的计算和通信开销。还可能产生脑裂。

什么是误判

主库实际没有下线，但是哨兵以为它下线了。误判产生原因：集群网络压力较大，网络拥塞，主库本身压力较大。

一旦哨兵判断主库下线，就会开始重新选择主库，并让从库和新主库进行数据同步，这个过程中本身就会有开销。

哨兵也要花时间选出新主库。因此我们需要减少误判。

少数服从多数

哨兵集群：哨兵多实例组成的集群模式进行部署。引入哨兵实例判断，避免单哨兵因为自身网络状况不好，误判主库下线的情况。同时，多搜啊并网络同时不稳定的概率较小，它们一起决策让误判率降低。

只有大多数哨兵实例判断主库都已经"主观下线"，主库才会被标记"客观下线"-----少数服从多数

"客观下线"：N个哨兵实例，最好要有N/2+1个实例判断主库为"主观下线"，才能判断为"客观下线"。

减少误判的概率，避免误判带来无谓的主从切换。

三.选定新主库

筛选+打分

筛选条件：

检查从库的当前在线状态，判断他之前的网络连接状态

如果从库总是和主库断连，断连次数超过一定阈值，该从库网络状态不好。

判断方式：

使用配置项down-after-milliseconds*10。down-after-milliseconds是我们认定主从库短链的最大连接超时时间。

断连次数超过10次，说明从库网络状态不好，不适合作为新主库。

从库打分：

按照三个规则依次进行三轮打分，这三个规则分别是从库优先级，从库复制进度和从库ID号。只要在某一轮中从库得分最高，他就是主库了。选主过程结束。如果没有出现得分最高的从库，那就会继续进行下一轮。

第一轮：优先级最高的从库得分高

通过配置slave-priority配置项，给不同从库设置不同优先级。比如两个从库内存大小不一样，可以手动设置内存大的实例设置为一个高优先级。选主时候哨兵会选出优先级最高的打高分作为新主库，如果得分一直，那就开始第二轮打分。

第二轮：和旧主库同步程度最接近的从库得分高

如果选择与旧主库同步最接近的从库作为主库，那么新主库上就有最新的数据。

如何判断从库和旧主库间的同步进度？

从库的slave_repl_offset最接近旧主库的master_repl_offset，那么它的得分最高，可以作为新主库。

如果两个从库的slave_repl_offset值大小一样，那么就需要进入第三轮打分了。

第三轮：ID号越小得分越高

每个实例在创建时候都会有一个ID，目前Redsi在选主从库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID号最小的从库得分最高，会被选为新主库。选主完成！

课后提问：

哨兵机制可以实现主从库的自由切换，这是实现服务不间断的关键支撑，主从切换是需要一定时间，在切换过程中客户端是否可以正常的进行请求操作，如何不感知的实现灰度切换。

客户端使用读写分离，那么读请求可以在从库上正常执行，不会受到影响。但是由于主库已经挂了，哨兵还没选出新主库，这时候写请求会失败，失败时间=哨兵切换主从时间+客户端感知到新主库时间。

方案1：

客户端将写失败的请求缓存或者写入消息队列中间件中，等哨兵切换完主从后，再执行这些命令，但是这种场景只适合对写入请求返回值不敏感的业务，而且还需要业务层做适配。如果主从切换时间过长，导致客户端或者消息队列中间件缓存写请求过多，切换完成后重放请求时间过长。

方案2：

哨兵检测主库多久没有响应就进行主从切换，可以配置down-after-milliseconds参数；

配置时间越短，哨兵越敏感，可能会导致误判。但是当主库真正故障，因为切换及时，对阢影响最小，如果配置时间越长，哨兵越保守，可以较少哨兵误判概率，主库故障发生时，业务写失败的时间也会较长。

方案3；

哨兵通知客户端，让客户端能够及时感知主库变化，将缓存的写请求写入新库中，保证后续写请求不会收到影响。

哨兵提升一个从库为新主库后，哨兵会把新主库的地址写入自己实例的pubsub。客户端订阅这个主题，当pubsub有数据时将最新主库地址推送给客户端，写请求写到这个新主库即可，这种机制属于哨兵主动通知客户端。

如果客户端因为某些原因错过推送通知，客户也需要主动回去这个主题信息。

客户端访问主从库时候，不能直接写死主从库的地址，需要从哨兵集群中获取最新地址（sentinel get-master-addr-by-name命令），这样哨兵切换后，客户端可以从哨兵集群中拿到最新的实例地址。
一般Redis的SDK都提供了通过哨兵拿到实例地址，再访问实例的方式，我们直接使用即可，不需要自己实现这些逻辑。对于只有主从实例的情况，客户端需要和哨兵配合使用，而在分片集群模式下，这些逻辑都可以做在proxy层，这样客户端也不需要关心这些逻辑了。

Redis核心技术与实战-学习笔记（七）哨兵机制相关推荐

Redis核心技术与实战-学习笔记（二十九）：Redis并发控制
一.需要并发控制的原因 Redis不可避免的会遇到并发访问问题,比如多用户同时下单,就会对缓存在Redis中的商品库存并发更新,一旦有了并发操作,数据就会被修改,如果我们没有对并发写请求做好控制,就可 ...
Redis核心技术与实战-学习笔记（五）内存快照RDB
一.为什么需要RDB AOF 方法优势:每次执行只需要记录操作命令,需要持久化的数据量不大.在进行写后日志只要不采用always(同步写回)的持久化策略就不会对性能造成太大影响. AOF方法劣势:AO ...
Redis核心技术与实战-学习笔记（三十五）Redis使用建议
键值对使用规范 key的命令规范,只有命名规范,才能提供可读性强,可维护性好的key,方便日常管理: value的设计规范,包括避免bigkey,选择高效序列化方法和压缩方法,使用整数对象共享池,数据 ...
Redis核心技术与实战-学习笔记（二十六）：缓存雪崩、击穿、穿透
一.缓存雪崩缓存雪崩:大量应用请求无法在Redis缓存中进行处理,应用请求频繁访问数据库,导致数据库压力激增. 产生原因: 缓存中有大量数据同时过期,导致大量请求无法得到处理数据保存在缓存中,并设 ...
Redis核心技术与实战-学习笔记（十五）：消息队列（Redis的解决方案）
一.消息队列消息队列:分布式系统必备的一个基础软件,能支持组件通信消息的快速读写 Redis本身支持数据的快速访问,满足消息队列的读写性能需求二.Redis适合做消息队列吗? 消息队列的消息存取需 ...
Redis核心技术与实战-学习笔记（十四）：时间序列数据
一.时间序列数据时间序列数据:没有严格的关系模型,记录的信息可以表示成键和值的关系. (例如,一个设备ID对应一条记录): 时间序列数据的读写特点持续高并发写入,需要连续记录数万个设备的实时状态值 ...
Elasticsearch核心技术与实战学习笔记 43 | 分页与遍历：From, Size, Search After Scroll API
一序本文属于极客时间Elasticsearch核心技术与实战学习笔记系列. 二分页 2.1 From / Size 默认情况下,查询按照相关度算分排序,返回前 10 条记录容易理解的分页方案 ...
Kafka 核心技术与实战学习笔记（二十四）请求处理过程
一.请求/响应所有的请求都是通过 TCP 网络以 Socket 的方式进行通讯的. Apache Kafka自定义的请求协议: PRODUCE请求是用于生产消息的 FETCH请求是用于消费消息的 M ...
极客时间 Redis核心技术与实战笔记（基础篇）
Redis 概览 Redis 知识全景图 Redis 问题画像图基础篇基本架构数据结构数据类型和底层数据结构映射关系全局哈希表链式哈希解决哈希冲突渐进式 rehash 不同数据结构查找操 ...

Redis核心技术与实战-学习笔记（七）哨兵机制