网站怎么做好优化,免费制作网站用什么做,镇江门户网站,公司门户网站目录
1.什么是哨兵机制#xff08;Redis Sentinel#xff09;
2.哨兵机制基本流程
3.哨兵获取主从服务器信息
4.多个哨兵进行通信
5.主观下线和客观下线
6.哨兵集群的选举
7.新主库的选出
8.故障的转移
9.基于pub/sub机制的客户端事件通知 1.什么是哨兵机制#xf…目录
1.什么是哨兵机制Redis Sentinel
2.哨兵机制基本流程
3.哨兵获取主从服务器信息
4.多个哨兵进行通信
5.主观下线和客观下线
6.哨兵集群的选举
7.新主库的选出
8.故障的转移
9.基于pub/sub机制的客户端事件通知 1.什么是哨兵机制Redis Sentinel Redis Sentinel即Redis哨兵在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。 哨兵机制sentinel是Redis解决高可用的一种解决方案它是由一个或者多个sentinel 实例组成的一个sentinel 系统。 下图是一个典型的哨兵集群监控的逻辑图 哨兵实现了什么功能呢下面是Redis官方文档的描述
监控Monitoring哨兵会不断地检查主节点和从节点是否运作正常。自动故障转移Automatic failover当主节点不能正常工作时哨兵会开始自动故障转移操作它会将失效主节点的其中一个从节点升级为新的主节点并让其他从节点改为复制新的主节点。配置提供者Configuration provider客户端在初始化时通过连接哨兵来获得当前Redis服务的主节点地址。通知Notification哨兵可以将故障转移的结果发送给客户端。
其中监控和自动故障转移功能使得哨兵可以及时发现主节点故障并完成转移而配置提供者和通知功能则需要在与客户端的交互中才能体现。
2.哨兵机制基本流程
sentinel(哨兵机制)其实就是一个运行在特殊模式下的Redis服务器。
在服务器初始化时普通Redis服务器初始化时会通过载入RDB文件或者AOF文件来恢复数据库状态而sentinel服务器由于不使用数据库所以它在初始化时无需载入RDB文件或者AOF文件。
我们先看监控。监控指的就是哨兵进程运行时它会周期性地心跳检测检测所有主从服务器是否正常运行。心跳检测方式为周期性向主从服务器发送PING命令若主从服务器在规定时间内响应哨兵进程则判断该服务器处于存活状态若主从服务器在规定时间内没有响应哨兵进程则哨兵进程会判定其下线。
如下图所示主服务器server2在规定时间内未响应sentinel进程则sentinel进程判断主服务器server2主观下线进行选举操作。 若主服务器处于下线状态时哨兵进程会进行故障转移也就是重新选主。选主就是会从其所属的多个从服务器中选举一个服务器作为新的主服务器来提供服务。选举成功后哨兵进程让已下线主服务器属下的所有从服务器去复制新的主服务器这一动作会通过向从服务器发送SLAVEOF命令来实现。
如下图则展示了在故障转移操作中server1已下线server2选举成为主节点,sentinel节点向已下线主服务器server1的两个从服务器server3发送SLAVEOF命令进行复制新的主服务器数据信息。 若旧的主服务器重新启动后会成为新的主服务器的从服务器。
如下图所示旧主服务器server1重新启动后会默认成为新主服务器server2的从服务器进行运行。 哨兵选举出新的主服务器后会将新主服务器信息发送给客户端让它和新的主服务器建立连接就行并不涉及决策的逻辑。但是在监控和选举过程中哨兵需要做出两个决策一个是判断主库是否下线第二个是在选举过程中选举哪个从服务器作为新的主服务器提供服务。
3.哨兵获取主从服务器信息
sentinel(哨兵)进程默认会以每隔10秒一次的频率通过命令连接向被连接的主服务器发送INFO命令并通过分析INFO命令返回的数据来获取主服务器的当前信息以及所属从服务器信息。
如下图所示主服务器server2和其三个从服务器server1、server3、server4。sentinel进程会向主服务器server2发送INFO命令主服务器会返回对应的主服务器和从服务器的信息。 同理sentinel进程也会向从服务器发送INFO命令获取从服务器对应的节点信息。频率默认10秒一次。 4.多个哨兵进行通信
在哨兵集群下哨兵实例进行通信是基于Redis提供的pub/sub机制的也就是发布/订阅模式。
在主从集群中哨兵节点不会直接与其他哨兵节点建立连接而是首先会和主库建立起连接然后向一个名为_sentinel_:hello频道发送自己的信息IPport其他订阅了该频道的哨兵节点就会获取到该哨兵节点信息从而哨兵节点之间互知。
通俗讲Redis哨兵模式中哨兵节点的互通是通过订阅指定的频道来进行的而不是直接与其他sentinel节点建立起连接。
举个例子假如现在有sentinel1、sentinel2、sentinel3三个sentinel在监控同一个服务器那么当sentinel1向主服务器的_sentinel_:hello频道发送一条信息时所有订阅了_sentinel_:hello频道的sentinel(包含sentinel自己在内)都会收到这条消息。如下图所示 当一个sentinel从_sentinel_:hello频道收到一条消息后sentinel会对这条信息进行分析提取出信息中的sentinel IP地址、sentinel端口号、sentinel运行ID等八个参数并进行检查
如果信息中记录的sentinel运行ID和接收信息的sentinel的运行ID相同那么说明这条消息是sentinel自己发送的sentinel将丢失这条信息不做进一步处理。相反地如果信息记录的sentinel运行ID和接收信息的sentinel的运行ID不相同那么说明这条信息是监控同一个服务器的其他sentinel发来的接收信息的sentinel将根据信息中的各个参数对相应主服务器的实例结构进行更新。
5.主观下线和客观下线 哨兵如何判断主库已经下线了呢 主观下线任何一个哨兵都是可以监控探测并作出Redis节点下线的判断客观下线有哨兵集群共同决定Redis节点是否下线
首先先解释一下什么是主观下线。
哨兵进程会使用PING命令的方式来检测各个主库和从库的网络连接情况用来判断实例状态。如果哨兵发现主库或者从库响应超时那么哨兵会判定其为主观下线。
如果哨兵检测从库发现从库在规定时间内未响应那么哨兵就会把它标记为主观下线因为从库的下线影响一般不太大集群的对外服务不会间断。但是如果检测主库哨兵不会简单把它标记为主观下线开启主从切换。
因为很有可能会有一种特殊情况哨兵误判。也就是说主库本身没有故障但由于哨兵的误判判断它为下线状态。一旦启动主从切换后续的选举和通知操作都会带来额外的计算和通信开销。因此为了不必要开销我们要严格注意误判的情况。
在哨兵集群中判定主库是否处于下线状态不是由一个哨兵来决定的而是只有大多数哨兵认为主库已经主观下线主库才会标记为客观下线。这种判断机制为少数服从多数。同时会触发主从切换模式。
举个例子现在有sentinel1、sentinel2、sentinel3三个哨兵和master1一个主库和slave1、slave2、slave3三个从服务器。但sentinel1和sentinel2 判断master1处于上线状态而sentinel3判断master1处于主观下线那么最终master1仍然为上线状态。 简单的来说客观下线的标准为当有N个实例最好要有N/21个哨兵实例认为其主观下线那么主库才是客观下线。这样的好处减少了误判的概率避免了不必要的开销。(当然有多个实例做出主线下线的判断才可以也可以由Redis管理员自行设定)
6.哨兵集群的选举 判断完主库下线后由哪个哨兵节点来执行主从切换呢这里就需要哨兵集群的选举机制了。 为什么必然会出现选举/共识机制
为了避免哨兵的单点情况发生所以需要一个哨兵的分布式集群。作为分布式集群必然涉及共识问题即选举问题同时故障的转移和通知都只需要一个主的哨兵节点就可以了。
哨兵的选举机制是什么样的
哨兵的选举机制其实很简单就是一个Raft选举算法 选举的票数大于等于num(sentinels)/21时将成为领导者如果没有超过继续选举
任何一个想成为 Leader 的哨兵要满足两个条件 第一拿到半数以上的赞成票第二拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。
以 3 个哨兵为例假设此时的 quorum 设置为 2那么任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票就可以了。 再看一个例子。Redis 1主4从5个哨兵哨兵配置quorum为2如果3个哨兵故障当主库宕机时哨兵能否判断主库“客观下线”能否自动切换 1、哨兵集群可以判定主库“主观下线”。由于quorum2所以当一个哨兵判断主库“主观下线”后询问另外一个哨兵后也会得到同样的结果2个哨兵都判定“主观下线”达到了quorum的值因此哨兵集群可以判定主库为“客观下线”。
2、但哨兵不能完成主从切换。哨兵标记主库“客观下线后”在选举“哨兵领导者”时一个哨兵必须拿到超过多数的选票(5/213票)。但目前只有2个哨兵活着无论怎么投票一个哨兵最多只能拿到2票永远无法达到N/21选票的结果。
7.新主库的选出 主库既然判定客观下线了那么如何从剩余的从库中选择一个新的主库呢 过滤掉不健康的下线或断线没有回复过哨兵ping响应的从节点选择salve-priority从节点优先级最高redis.conf的选择复制偏移量最大只复制最完整的从节点 8.故障的转移 新的主库选择出来后就可以开始进行故障的转移了。 假设判断主库客观下线了同时选出sentinel 3是哨兵leader 故障转移流程如下 将slave-1脱离原从节点PS: 5.0 中应该是replicaof no one)升级主节点将从节点slave-2指向新的主节点通知客户端主节点已更换将原主节点oldMaster变成从节点指向新的主节点
转移之后 9.基于pub/sub机制的客户端事件通知
从本质上说哨兵就是一个运行在特定模式的Redis只不过它并不服务于请求操作只是完成监控、故障转移、通知的任务。每个哨兵提供pub/sub机制客户端可以从哨兵订阅消息。
客户端可以从哨兵订阅所有事件这样客户端不仅可以在主从切换后得到新主库的连接信息还可以监控主从库切换过程中发生的各个重要事件。
有了pub/sub机制哨兵和哨兵之间、哨兵与从库之间、哨兵与客户端之间就能连接起来了再加上上述将的主库判断依据和选举依据哨兵集群的监控、选举、通知三个任务就可以正常运行了。
总结
sentinel只是一个运行在特殊环境下的Redis不提供数据存储服务。sentinel会通过向主服务器发送INFO命令获取主服务器所属的从服务器的地址信息并为这些从服务器创建相应的实例结构以及向这些从服务器发送命令连接和订阅连接。
在一般情况下sentinel会以每10s一次的频率向被监视的主库和从库发送INFO命令获取主库和从库的相关信息。当主库处于下线状态或者sentinel正对主服务器进行故障转移操作时sentinel向从服务发送INFO命令的频率修改为每秒一次。对于监控同一个主服务器的哨兵来说他们通过向主服务器的_sentinel_:hello发送消息来向其他sentinel告知自己的存在。其他订阅了该频道的sentinel都可以接收到从而各个sentinel互知。
sentinel只会与主服务器和从服务器之间建立命令连接和订阅连接而sentinel之间只会建立命令建立进行通信。sentinel会以每秒一次的频率向实例从服务器、主服务器、其他sentinel发送PING命令并根据实例对PING命令的回复来判断实例是否在线当一个实例在指定时间内未响应PING命令则判定其为主观下线。
在哨兵集群下当sentinel收到足够多的主观下线投票之后他会将主服务器判断为客观下线并发起一个针对主服务器的故障转移操作。
参考1.一文读懂Redis的哨兵机制 - 知乎 (zhihu.com) 2.Redis设计与实现 书籍
