济宁市中网站建设,广东省城乡住房建设厅网站首页,wordpress tag无法找到该页,wordpress和帝国哪个好Sentinel简述
Sentinel为了解决什么问题#xff1f;
Sentinel#xff08;哨岗、哨兵#xff09;是Redis的高可用性#xff08;high availability#xff09;解决方案。
我们知道Redis 的主从复制模式可以将主节点的数据改变同步给从节点#xff0c;这样从节点就可以起…Sentinel简述
Sentinel为了解决什么问题
Sentinel哨岗、哨兵是Redis的高可用性high availability解决方案。
我们知道Redis 的主从复制模式可以将主节点的数据改变同步给从节点这样从节点就可以起到以下作用 作为主节点的一个备份一旦主节点出了故障不可达的情况从节点可以作为后备“顶”上来并且保证数据尽量不丢失(主从复制是最终一致性)。 从节点可以扩展主节点的读能力一旦主节点不能支撑住大并发量的读操作从节点可以在一定程度上帮助主节点分担读压力。
但是主从复制也带来了以下问题: 一旦主节点出现故障需要手动将一个从节点晋升为主节点同时需要修改应用方的主节点地址还需要命令其他从节点去复制新的主节点,整个过程都需要人工干预。可用性比较差。 主节点的写能力受到单机的限制。 主节点的存储能力受到单机的限制。
Sentinel是什么
它是一种解决方案一般由多个Sentinel实例组成的Sentinel系统。 一个Sentinel实例是一个特殊化redis客户端。不再具备数据读写能力。
Sentinel工作流程
由一个或多个Sentinel实例instance组成的Sentinel系统system可以监视任意多个主服务器以及这些主服务器属下的所有从服务器并在被监视的主服务器进入下线状态时自动将下线主服务器属下的某个从服务器升级为新的主服务器然后由新的主服务器代替已下线的主服务器继续处理命令请求。
Sentinel与主从架构的Redis关系图 server1为主服务器 server2server3server4为从服务器。 server2、server3、server4三个从服务器正在复制主服务器server1而Sentinel系统则在监视所有四个服务器。
Sentinel的全局流程
Sentinel的工作状态流转
Sentinel完成初始化开始监听假设这时主服务器server1进入下线状态。从服务器server2、server3、server4对主服务器的复制操作将被中止并且Sentinel系统会察觉到server1已下线。当server1的下线时长超过用户设定的下线时长上限时Sentinel系统就会对server1执行故障转移操作 首先Sentinel系统会挑选server1属下的其中一个从服务器并将这个被选中的从服务器升级为新的主服务器。 之后Sentinel系统会向server1属下的所有从服务器发送新的复制指令让它们成为新的主服务器的从服务器 当所有从服务器都开始复制新的主服务器时故障转移操作执行完毕。 另外Sentinel还会继续监视已下线的server1并在它重新上线时将它设置为新的主服务器的从服务器。
Sentinel的初始化
1.启动Sentinel的命令
$ redis-sentinel /path/to/your/sentinel.conf$ redis-server /path/to/your/sentinel.conf --sentinel2.启动Sentinel的内部流程
当一个Sentinel启动时它需要执行以下步骤
1初始化服务器。 因为Sentinel执行的工作和普通Redis服务器执行的工作不同所以Sentinel的初始化过程和普通Redis服务器的初始化过程并不完全相同。
例如普通服务器在初始化时会通过载入RDB文件或者AOF文件来还原数据库状态但是因为Sentinel并不使用数据库所以初始化Sentinel时就不会载入RDB文件或者AOF文件。
2将普通Redis服务器使用的代码替换成Sentinel专用代码。
3初始化Sentinel状态。
4根据给定的配置文件初始化Sentinel的监视主服务器列表。
5创建连向主服务器的网络连接。 初始化Sentinel的最后一步是创建连向被监视主服务器的网络连接Sentinel将成为主服务器的客户端它可以向主服务器发送命令并从命令回复中获取相关的信息。
对于每个被Sentinel监视的主服务器来说Sentinel会创建两个连向主服务器的异步网络连接
·一个是命令连接这个连接专门用于向主服务器发送命令并接收命令回复。
·另一个是订阅连接这个连接专门用于订阅主服务器的__sentinel__:hello频道。为了发现新加入的Sentinel实例
Sentinel的通信功能
作为一套合理的监控机制Sentinel必须用合理的通信功能来保证对主节点从节点以及不同Sentinel实例之间的信息交流。
Sentinel通过三个定时监控任务完成对各个节点发现和监控。
每隔十秒的定时任务INFO命令
Sentinel默认会以每十秒一次的频率通过命令连接向被监视的主服务器和从服务器发送INFO命令并通过分析INFO命令的回复来获取主服务器的当前信息。 INFO命令的作用
获取主服务器信息获取从服务器信息节点不可达或者故障转移后可以实时更新节点拓扑信息
这三个作用其实都是从返回的信息中进行解析做到的。 类似于以下内容的回复
# Server
...
run_id:7611c59dc3a29aa6fa0609f841bb6a1019008a9c
...
# Replication
role:master
...
slave0:ip127.0.0.1,port11111,stateonline,offset43,lag0
slave1:ip127.0.0.1,port22222,stateonline,offset43,lag0
slave2:ip127.0.0.1,port33333,stateonline,offset43,lag0
...
# Other sections
...INFO命令返回值的内容
通过分析主服务器返回的INFO命令回复Sentinel可以获取以下两方面的信息
一方面是关于主服务器本身的信息包括run_id域记录的服务器运行ID以及role域记录的服务器角色
根据run_id域和role域记录的信息Sentinel将对主服务器的实例结构进行更新。
例如主服务器重启之后它的运行ID就会和实例结构之前保存的运行ID不同Sentinel检测到这一情况之后就会对实例结构的运行ID进行更新。另一方面是关于主服务器属下所有从服务器的信息每个从服务器都由一个slave字符串开头的行记录每行的ip域记录了从服务器的IP地址而port域则记录了从服务器的端口号。根据这些IP地址和端口号Sentinel无须用户提供从服务器的地址信息就可以自动发现从服务器。 于主服务器返回的从服务器信息则会被用于更新主服务器实例结构的slaves字典这个字典记录了主服务器属下从服务器的名单.Sentinel在分析INFO命令中包含的从服务器信息时会检查从服务器对应的实例结构是否已经存在于slaves字典,如果从服务器对应的实例结构已经存在那么Sentinel对从服务器的实例结构进行更新。如果从服务器对应的实例结构不存在那么说明这个从服务器是新发现的从服务器Sentinel会在slaves字典中为这个从服务器新创建一个实例结构。当Sentinel发现主服务器有新的从服务器出现时Sentinel除了会为这个新的从服务器创建相应的实例结构之外Sentinel还会创建连接到从服务器的命令连接和订阅连接。每隔两秒的定时任务publish/subscribe
publish 在默认情况下Sentinel会以每两秒一次的频率通过命令连接向所有被监视的主服务器和从服务器发送以下格式的命令
PUBLISH __sentinel__:hello s_ip,s_port,s_runid,s_epoch,m_name,m_ip,m_port,m_epoch·其中以s_开头的参数记录的是Sentinel本身的信息。
·而m_开头的参数记录的则是主服务器的信息。 如果Sentinel正在监视的是主服务器那么这些参数记录的就是主服务器的信息如果Sentinel正在监视的是从服务器那么这些参数记录的就是从服务器正在复制的主服务器的信息。
subscribe 当Sentinel与一个主服务器或者从服务器建立起订阅连接之后Sentinel就会通过订阅连接向服务器发送以下命令
SUBSCRIBE __sentinel__:helloSentinel对__sentinel__:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止。
这也就是说对于每个与Sentinel连接的服务器Sentinel既通过命令连接向服务器的__sentinel__:hello频道发送信息又通过订阅连接从服务器的__sentinel__:hello频道接收信息
作用 通过这个定时任务的publish和subscribe命令多个sentinel实例之间可以进行对于监控节点的信息校验和分析也可以更新对其他sentinel实例的信息因为他们同样都监听了服务器的__sentinel__:hello频道。 当Sentinel通过频道信息发现一个新的Sentinel时它不仅会为新Sentinel在sentinels字典中创建相应的实例结构还会创建一个连向新Sentinel的命令连接。 各个Sentinel之间的网络连接最终形成以下结构 使用命令连接相连的各个Sentinel可以通过向其他Sentinel发送命令请求来进行信息交换
这是客观下线和领导者选举的依据
每隔一秒的定时任务ping
心跳监测 每隔1秒每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测来确认这些节点当前是否可达。
Sentinel对于服务器的下线检测
主观下线 每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测,当这些节点超过down-after-milliseconds没有进行有效回复Sentinel节点就会对该节点做失败判定这个行为叫做主观下线。从字面意思也可以很容易看出主观下线是当前Sentinel节点的一家之言,存在误判的可能。
· 有效回复实例返回PONG、-LOADING、-MASTERDOWN三种回复的其中一种。
· 无效回复实例返回除PONG、-LOADING、-MASTERDOWN三种回复之外的其他回复或者在指定时限内没有返回任何回复。
客观下线
当Sentinel主观下线的节点是主节点时该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断当超过quorum个数,Sentinel节点认为主节点确实有问题这时该Sentinel节点会做出客观下线的决定这样客观下线的含义是比较明显了也就是大部分Sentinel节点都对主节点的下线做了同意的判定那么这个判定就是客观的。
Sentinel的领导者选举
假如Sentinel节点对于主节点已经做了客观下线那么是不是就可以立即进行故障转移了 当然不是实际上故障转移的工作只需要一个Sentinel节点来完成即可所以 Sentinel节点之间会做一个领导者选举的工作选出一个Sentinel节点作为领导者进行故障转移的工作。Redis使用了Raft算法实现领导者选举。
大致过程如下 1 )每个在线的Sentinel节点都有资格成为领导者当它确认主节点主观下线时候会向其他Sentinel节点发送sentinel is-master-down-by-addr命令要求将自己设置为领导者。
2)收到命令的Sentinel节点如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令,将同意该请求,否则拒绝。
3如果该Sentinel节点发现自己的票数已经大于等于max (quorumnum(sentinels)/21,那么它将成为领导者。
4如果此过程没有选举出领导者,将进入下一次选举。
选举的过程非常快,基本上谁先完成客观下线,谁就是领导者。
Raft算法 Sentinel系统选举领头Sentinel的方法是对Raft算法的领头选举方法的实现关于这一方法的详细信息可以观看Raft算法的作者录制的“Raft教程”视频Raft教程或者Raft算法的论文。
Raft协议的详细版本
raft-zh_cn/raft-zh_cn.md at master · maemual/raft-zh_cn · GitHub
如果你想手写一个Raft协议可以看下蚂蚁金服的开发生产的raft算法组件
[GitHub - sofastack/sofa-jraft: A production-grade java implementation of RAFT consensus algorithm.](Sentinel的故障转移
在选举产生出领头Sentinel之后领头Sentinel将对已下线的主服务器执行故障转移操作该操作包含以下三个步骤
1在已下线主服务器属下的所有从服务器里面挑选出一个从服务器并将其转换为主服务器。
2让已下线主服务器属下的所有从服务器改为复制新的主服务器。
3将已下线主服务器设置为新的主服务器的从服务器当这个旧的主服务器重新上线时它就会成为新的主服务器的从服务器。
选取新的主服务器 1)在从节点列表中选出一个节点作为新的主节点,选择方法如下:
a)过滤:“不健康”(主观下线、断线)、5秒内没有回复过Sentinel节点 INFO命令、与主节点失联超过down-after-milliseconds*10毫秒
b)选择slave-priority(从节点优先级)最高的从节点列表如果存在则返回,不存在(有多个具有最高优先级的从服务器)则继续。
c选择复制偏移量最大的从节点(复制的最完整)如果存在则返回,不存在则继续。
d选择runid最小的从节点。
2 ) Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
在发送SLAVEOF no one命令之后领头Sentinel会以每秒一次的频率平时是每十秒一次向被升级的从服务器发送INFO命令并观察命令回复中的角色role信息当被升级服务器的role从原来的slave变为master时领头Sentinel就知道被选中的从服务器已经顺利升级为主服务器了。
3 ) Sentinel领导者节点会向剩余的从节点发送命令让它们成为新主节点的从节点,复制规则和parallel-syncs参数有关。 领头Sentinel向已下线主服务器server1的两个从服务器server3和server4发送SLAVEOF命令让它们复制新的主服务器server2的例子。
4 ) Sentinel节点集合会将原来的主节点更新为从节点并保持着对其关注当其恢复后命令它去复制新的主节点。 当server1重新上线时Sentinel就会向它发送SLAVEOF命令让它成为server2的从服务器。
Sentinel的一些问题
为什么在Sentinel模式下Redis不能执行Set等命令
Sentinel只是一个运行在特殊模式下的Redis服务器它使用了和普通模式不同的命令表所以Sentinel模式能够使用的命令和普通Redis服务器能够使用的命令不同。
Sentunel为什么要和主从节点建立两个连接
Sentinel会读入用户指定的配置文件为每个要被监视的主服务器创建相应的实例结构并创建连向主服务器的命令连接和订阅连接其中命令连接用于向主服务器发送命令请求而订阅连接则用于接收指定频道的消息。
在Redis目前的发布与订阅功能中被发送的信息都不会保存在Redis服务器里面如果在信息发送时想要接收信息的客户端不在线或者断线那么这个客户端就会丢失这条信息。因此为了不丢失__sentinel__:hello频道的任何信息Sentinel必须专门用一个订阅连接来接收该频道的信息。
大家如果还有其他相关问题的话可以写在评论里我尽量及时回复并且更新到文章中
