这篇文章主要为大家展示了“Redis中sentinel故障转移的示例分析”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“Redis中sentinel故障转移的示例分析”这篇文章吧。

当两台以上的Redis实例形成了主备关系,它们组成的集群就具备了一定的高可用性:当master发生故障的时候,slave可以成为新的master对外提供读写服务,这种运营机制成为failover。

那么谁来发现master的故障做failover决策?

一种方式是,保持一个daemo进程,监控着所有的master-slave节点,如下图所示:

一个Redis集群里面有一个master和两个slave,这个daemon进程监控着这三个节点。但daemon为单节点,本身可用性无法保证。需要引入多daemon,如下图所示:

多个daemon解决了可用性问题,但又出现了一致性问题,如何就某个master是否可用达成一致?例如上图两个daemon1和和master网络不通,daemon和master连接畅通,那此时mater节点是否需要failover那?

Redis的sentinel提供了一套多daemon间的交互机制,多个daemon间组成一个集群,成为sentinel集群,daemon节点也称为sentinel节点。如下图所示:

这些节点相互间通信、选举、协商,在master节点的故障发现、failover决策上表现出一致性。

sentinel集群监视任意多个master以及master下的slave,自动将下线的master从其下的某个slave升级为新的master代替继续处理命令请求。

启动并初始化Sentinel

启动一个Sentinel可以使用命令:

./redis-sentinel../sentinel.conf

或者命令:

./redis-server../sentinel.conf--sentinel

当一个Sentinel启动时,它需要执行以下步骤:

初始化服务器

Sentinel本质上是运行在特殊模式下的Redis服务器,它和普通的Redis服务器执行的工作不同,初始化过程也不完全相同。如普通的Redis服务器初始化会载入RDB或者AOF文件来恢复数据,而Sentinel启动时不会载入,因为Sentinel并不使用数据库。

将普通Redis服务器使用的代码替换成Sentinel专用代码

将一部分普通Redis服务器使用的代码替换成Sentinel专用代码。如普通Redis服务器使用server.c/redisCommandTable作为服务器的命令表:

tructredisCommandredisCommandTable[]={{"module",moduleCommand,-2,"as",0,NULL,0,0,0,0,0},{"get",getCommand,2,"rF",0,NULL,1,1,1,0,0},{"set",setCommand,-3,"wm",0,NULL,1,1,1,0,0},{"setnx",setnxCommand,3,"wmF",0,NULL,1,1,1,0,0},{"setex",setexCommand,4,"wm",0,NULL,1,1,1,0,0},{"psetex",psetexCommand,4,"wm",0,NULL,1,1,1,0,0},{"append",appendCommand,3,"wm",0,NULL,1,1,1,0,0},.....{"del",delCommand,-2,"w",0,NULL,1,-1,1,0,0},{"unlink",unlinkCommand,-2,"wF",0,NULL,1,-1,1,0,0},{"exists",existsCommand,-2,"rF",0,NULL,1,-1,1,0,0},{"setbit",setbitCommand,4,"wm",0,NULL,1,1,1,0,0},{"getbit",getbitCommand,3,"rF",0,NULL,1,1,1,0,0},{"bitfield",bitfieldCommand,-2,"wm",0,NULL,1,1,1,0,0},{"setrange",setrangeCommand,4,"wm",0,NULL,1,1,1,0,0},{"getrange",getrangeCommand,4,"r",0,NULL,1,1,1,0,0},{"substr",getrangeCommand,4,"r",0,NULL,1,1,1,0,0},{"incr",incrCommand,2,"wmF",0,NULL,1,1,1,0,0},{"decr",decrCommand,2,"wmF",0,NULL,1,1,1,0,0},{"mget",mgetCommand,-2,"rF",0,NULL,1,-1,1,0,0},{"rpush",rpushCommand,-3,"wmF",0,NULL,1,1,1,0,0},{"lpush",lpushCommand,-3,"wmF",0,NULL,1,1,1,0,0}......}

Sentinel使用sentinel.c/sentinelcmds作为服务器列表,如下所示:

structredisCommandsentinelcmds[]={{"ping",pingCommand,1,"",0,NULL,0,0,0,0,0},{"sentinel",sentinelCommand,-2,"",0,NULL,0,0,0,0,0},{"subscribe",subscribeCommand,-2,"",0,NULL,0,0,0,0,0},{"unsubscribe",unsubscribeCommand,-1,"",0,NULL,0,0,0,0,0},{"psubscribe",psubscribeCommand,-2,"",0,NULL,0,0,0,0,0},{"punsubscribe",punsubscribeCommand,-1,"",0,NULL,0,0,0,0,0},{"publish",sentinelPublishCommand,3,"",0,NULL,0,0,0,0,0},{"info",sentinelInfoCommand,-1,"",0,NULL,0,0,0,0,0},{"role",sentinelRoleCommand,1,"l",0,NULL,0,0,0,0,0},{"client",clientCommand,-2,"rs",0,NULL,0,0,0,0,0},{"shutdown",shutdownCommand,-1,"",0,NULL,0,0,0,0,0},{"auth",authCommand,2,"sltF",0,NULL,0,0,0,0,0}}

初始化Sentinel状态

服务器会初始化一个sentinel.c/sentinelState结构(保存服务器中所有和Sentinel功能有关的状态)。

structsentinelState{charmyid[CONFIG_RUN_ID_SIZE+1];/*ThissentinelID.*///当前纪元,用于实现故障转移uint64_tcurrent_epoch;/*Currentepoch.*///监视的主服务器//字典的键是主服务器的名字//字典的值则是一个指向sentinelRedisInstances结构的指针dict*masters;/*DictionaryofmastersentinelRedisInstances.Keyistheinstancename,valueisthesentinelRedisInstancestructurepointer.*///是否进入tilt模式inttilt;/*AreweinTILTmode?*///目前正在执行的脚本数量intrunning_scripts;/*Numberofscriptsinexecutionrightnow.*///进入tilt模式的时间mstime_ttilt_start_time;/*WhenTITLstarted.*///最后一次执行时间处理器的时间mstime_tprevious_time;/*Lasttimeweranthetimehandler.*///一个FIFO队列,包含了所有需要执行的用户脚本list*scripts_queue;/*Queueofuserscriptstoexecute.*/char*announce_ip;/*IPaddrthatisgossipedtoothersentinelsifnotNULL.*/intannounce_port;/*Portthatisgossipedtoothersentinelsifnonzero.*/unsignedlongsimfailure_flags;/*Failuressimulation.*/intdeny_scripts_reconfig;/*AllowSENTINELSET...tochangescriptpathsatruntime?*/}

根据给定的配置文件,初始化Sentinel的监视主服务器列表

对Sentinel状态的初始化将引发对masters字典的初始化,而master字典的初始化是根据被载入的Sentinel配置文件来进行的。

字典的key是监视主服务器的名字,字典的值则是被监控主服务器对应的sentinel.c/sentinelRedisInstance结构。

sentinelRedisInstance结构部分属性如下:

typedefstructsentinelRedisInstance{//标识值,记录了实例的类型,以及该实例的当前状态intflags;/*SeeSRI_...defines*///实例的名字//主服务器的名字由用户在配置文件中设置//从服务器以及Sentinel的名字由Sentinel自动设置//格式为ip:port,例如“127.0.0.1:26379”char*name;/*Masternamefromthepointofviewofthissentinel.*///实例运行的IDchar*runid;/*RunIDofthisinstance,oruniqueIDifisaSentinel.*///配置纪元,用于实现故障转移uint64_tconfig_epoch;/*Configurationepoch.*///实例的地址sentinelAddr*addr;/*Masterhost.*///sentineldown-after-milliseconds选项设定的值//实例无响应多少毫秒之后才会被判断为主观下线(subjectivelydown)mstime_tdown_after_period;/*Consideritdownafterthatperiod.*///sentinelmonitor<master-name><ip><redis-port><quorum>选项中的quorum//判断这个实例为客观下线(objectivedown)所需的支持投票的数量unsignedintquorum;/*Numberofsentinelsthatneedtoagreeonfailure.*///sentinelparallel-syncs<master-name><numreplicas>选项的numreplicas值//在执行故障转移操作时,可以同时对新的主服务器进行同步的从服务器数量intparallel_syncs;/*Howmanyslavestoreconfigureatsametime.*///sentinelfailover-timeout<master-name><milliseconds>选项的值//刷新故障迁移状态的最大时限mstime_tfailover_timeout;/*Maxtimetorefreshfailoverstate.*/}

例如启动Sentinel时,配置了如下的配置文件:

#sentinelmonitor<master-name><ip><redis-port><quorum>sentinelmonitormaster1127.0.0.163792#sentineldown-after-milliseconds<master-name><milliseconds>sentineldown-after-millisecondsmaster130000#sentinelparallel-syncs<master-name><numreplicas>sentinelparallel-syncsmaster11#sentinelfailover-timeout<master-name><milliseconds>sentinelfailover-timeoutmaster1900000

则Sentinel则会为主服务器master1创建如下图所示的实例结构:

Sentinel状态以及masters字典的机构如下:

创建连向主服务器的网络连接

创建连向被监视主服务器的网络连接,Sentinel将成为主服务器的客户端,向主服务器发送命令并从命令回复获取信息。

Sentinel会创建两个连向主服务器的异步网络连接:

命令连接,用于向主服务器发送命令并接收命令回复

订阅连接,订阅主服务器的_sentinel_:hello频道

Sentinel发送信息和获取信息

Sentinel默认会以每十秒一次的频率,通过命令连接向被监视的master和slave发送INFO命令。

通过master的回复可获取master本身信息,包括run_id域记录的服务器运行ID,以及role域记录的服务器角色。另外还会获取到master下的所有的从服务器信息,包括slave的ip地址和port端口号。Sentinel无需用户提供从服务器的地址信息,由master返回的slave的ip地址和port端口号,可以自动发现slave。

当Sentinel发现master有新的slave出现时,Sentinel会为这个新的slave创建相应的实例外,Sentinel还会创建到slave的命令连接和订阅连接。

根据slave的INFO命令的回复,Sentinel会提取如下信息:

1.slave的运行ID run_id

2.slave的角色role

3.master的ip地址和port端口

4.master和slave的连接状态master_link_status

5.slave的优先级slave_priority

6.slave的复制偏移量slave_repl_offset

Sentinel在默认情况下会以每两秒一次的频率,通过命令连接向所有被监视的master和slave的_sentinel_:hello频道发送一条信息

发送以下格式的命令:

PUBLISH_sentinel_:hello"<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>"

以上命令相关参数意义:

参数意义s_ipSentinel的ip地址s_portSentinel的端口号s_runidSentinel的运行IDs_runidSentinel的运行IDm_name主服务器的名字m_ip主服务器的IP地址m_port主服务器的端口号m_epoch主服务器当前的配置纪元

Sentinel与master或者slave建立订阅连接之后,Sentinel就会通过订阅连接发送对_sentinel_:hello频道的订阅,订阅会持续到Sentinel与服务器的连接断开为止

命令如下所示:

SUBSCRIBE sentinel:hello

如上图所示,对于每个与Sentinel连接的服务器 ,Sentinel既可以通过命令连接向服务器频道_sentinel_:hello频道发送信息,又通过订阅连接从服务器的_sentinel_:hello频道接收信息。

sentinel间会相互感知,新加入的sentinel会向master的_sentinel_:hello频道发布一条消息,包括自己的消息,其它该频道订阅者sentinel会发现新的sentinel。随后新的sentinel和其它sentinel会创建长连接。

相互连接的各个Sentinel可以进行信息交换。Sentinel为master创建的实例结构中的sentinels字典保存了除Sentinel本身之外,所有同样监视这个主服务器的其它Sentinel信息。

前面也讲到sentinel会为slave创建实例(在master实例的slaves字典中)。现在我们也知道通过sentinel相互信息交换,也创建了其它sentinel的实例(在master实例的sentinels字典中)。我们将一个sentinel中保存的实例结构大概情况理一下,如下图所示:

从上图可以看到slave和sentinel字典的键由其ip地址和port端口组成,格式为ip:port,其字典的值为其对应的sentinelRedisInstance实例。

master的故障发现

主观不可用

默认情况下Sentinel会以每秒一次的频率向所有与它创建了命令连接的master(包括master、slave、其它Sentinel)发送PING命令,并通过实例返回的PING命令回复来判断实例是否在线。

PING命令回复分为下面两种情况:

有效回复:实例返回 +PONG、-LOADING、-MASTERDOWN三种回复的一种

无效回复:除上面有效回复外的其它回复或者在指定时限内没有任何返回

Sentinel配置文件中的设置down-after-milliseconds毫秒时效内(各个sentinel可能配置的不相同),连续向Sentinel返回无效回复,那么sentinel将此实例置为主观下线状态,在sentinel中维护的该实例flags属性中打开SRI_S_DOWN标识,例如master如下所示:

客观不可用

在sentinel发现主观不可用状态后,它会将“主观不可用状态”发给其它sentinel进行确认,当确认的sentinel节点数>=quorum,则判定该master为客观不可用,随后进入failover流程。

上面说到将主观不可用状态发给其它sentinel使用如下命令:

SENTINELis-master-down-by-addr<ip><port><current_epoch><runid>

各个参数的意义如下:

ip:被sentinel判断为主观下线的主服务器的ip地址

port: 被sentinel判断为主观下线的主服务器的port地址

current_epoch:sentinel的配置纪元,用于选举领头Sentinel

runid:可以为*号或者Sentinel的运行ID,*号代表检测主服务器客观下线状态。Sentinel的运行ID用于选举领头Sentinel

接受到以上命令的sentinel会反回一条包含三个参数的Multi Bulk回复:

1)<down_state> 目标sentinel对该master检查结果,1:master已下线 2:master未下线

2)<leader_runid> 两种情况,*表示仅用于检测master下线状态 ,否则表示局部领头Sentinel的运行ID(选举领头Sentinel)

3)<leader_epoch> 当leader_runid为时,leader_epoch始终为0。不为时则表示目标Sentinel的局部领头Sentinel的配置纪元(用于选举领头Sentinel)

其中节点数量限制quorum为sentinel配置文件中配置的

sentinelmonitor<master-name><ip><redis-port><quorum>

quorum选项,不同的sentinel配置的可能不相同。

当sentinel认为master为客观下线状态,则会将master属性中的flags的SRI_O_DOWN标识打开,例如master如下图所示:

选举Sentinel Leader

当一台master宕机时,可能多个sentinel节点同时发现并通过交互确认相互的“主观不可用状态”,同时达到“客观不可用状态”,同时打算发起failover。但最终只能有一个sentinel节点作为failover发起者,那么就需要选举出Sentinel Leader,需要开始一个Sentinel Leader选举过程。

Redis的Sentinel机制采用类似于Raft协议实现这个选举算法:

1.sentinelState的epoch变量类似于raft协议中的term(选举回合)。

2.每一个确认了master“客观不可用”的sentinel节点都会向周围广播自己的参选请求(SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <run_id> ,current_epoch为自己的配置纪元,run_id为自己的运行ID)

3.每一个接收到参选请求的sentinel节点如果还没接收到其它参选请求,它就将本回合的意向置为首个参选sentinel并回复它(先到先得);如果已经在本回合表过意向了,则拒绝其它参选,并将已有意向回复(如上所介绍的三个参数的Multi Bulk回复,down_state为1,leader_runid为首次接收到的发起参选请求的源sentinel的运行ID,leader_epoch为首次接收到的发起参选请求的源sentinel的配置纪元)

4.每个发起参选请求的sentinel节点如果收到超过一半的意向同意某个参选sentinel(可能是自己),则确定该sentinel为leader。如果本回合持续了足够长时间未选出leader,则开启下一个回合

leader sentinel 确定之后,leader sentinel从master所有的slave中依据一定规则选取一个作为新的master。

故障转移failover

在选举出Sentinel Leader之后,sentinel leader对已下线master执行故障转移:

sentinel leader对已下线的master的所有slave中,选出一个状态良好、数据完整的slave,然后向这个slave发送:SLAVEOF no one 命令,将这个slave转换为master。

我们来看下新的master是怎么挑选出来的?Sentinel leader会将已下线的所有slave保存到一个列表,然后按照以下规则过滤筛选:

优先级最高的slave,redis.conf配置中replica-priority选项来标识,默认为100,replica-priority较低的优先级越高。0为特殊优先级,标志为不能升级为master。

如果存在多个优先级相等的slave,则会选择复制偏移量(offset)最大的slave(数据更加完整)

如果存在多个优先级相等,最大复制偏移量最大的slave,则选择运行ID最小的slave

选出需要升级为新的master的slave后,Sentinel Leader会向这个slave发送SLAVEOF no one 命令。之后Sentinel会以每秒一次频率(平时是十秒一次)向被升级slave发送INFO,当回复的role由slave变为master时Sentinel Leader就会知道已升级为master。

sentinel leader 向已下线的master属下的slave发送SLAVEOF命令(SLAVEOF <new_master_ip> <new_master_port>),去复制新的master。

将旧的master设置为新的master的slave,并继续对其监视,当其重新上线时Sentinel会执行命令让其成为新的master的slave。

以上是“Redis中sentinel故障转移的示例分析”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!