快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

Redis的哨兵机制 Sentinel(简要)

请联系QQ:1793040 索取软件

Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务:
监控(Monitoring):Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒(Notification):当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统, 你可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个从服务器作为新的主服务器。
虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel , 但实际上它只是一个运行在特殊模式下的 Redis 服务器, 你可以在启动一个普通 Redis 服务器时通过给定–sentinel 选项来启动Redis Sentinel 。

相关术语说明
Sentinel包括两个重要的术语:<主观下线和客观下线>

1.主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。
2.客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断, 并且通过SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。

客观下线条件只适用于主服务器:对于任何其他类型的 Redis 实例, Sentinel 在将它们判断为下线前不需要进行协商, 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。
只要一个 Sentinel 发现某个主服务器进入了客观下线状态, 这个Sentinel 就可能会被其他 Sentinel 推选出, 并对失效的主服务器执行自动故障迁移操作。

每个Sentinel实例都执行的定时任务

1.每个Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
2.如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是:+PONG 、-LOADING 或者-MASTERDOWN 。
3.如果一个主服务器被标记为主观下线, 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
4.如果一个主服务器被标记为主观下线, 并且有足够数量的 Sentinel (至少要达到配置文件指定的数量)在指定的时间范围内同意这一判断, 那么这个主服务器被标记为客观下线。
5.在一般情况下, 每个 Sentinel 会以每10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时, Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
6.当没有足够数量的 Sentinel 同意主服务器已经下线, 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时, 主服务器的主管下线状态就会被移除。



Redis-sentinel原理分析
1)SDOWN 和 ODOWN 转换过程
【名词解释】
  SDOWN:subjectively down,直接翻译的为”主观”失效,即当前 sentinel 实例认为某个redis 服务为”不可用”状态。
  ODOWN:objectively down,直接翻译为”客观”失效,即多个 sentinel 实例都认为 master处于”SDOWN”状态,那么此时 master 将处于 ODOWN,ODOWN 可以简单理解为 master已经被集群确定为”不可用”,将会开启 failover。
  ( SDOWN 适合于 master 和 slave,但是 ODOWN 只会使用于 master;当 slave 失效超过”down-after-milliseconds”后,那么所有 sentinel 实例都会将其标记为”SDOWN”。)

【转换过程】
  a.每个 sentinel 实例在启动后,都会和已知的 slaves/master 以及其他 sentinels 建立 TCP连接,并周期性发送 PING(默认为 1 秒);
  b.在交互中,如果 redis-server 无法在”down-after-milliseconds”时间内响应或者响应错误信息,都会被认为此 redis-server 处于 SDOWN 状态;
  c.如果 b.中 SDOWN 的 server 为 master, 那么此时 sentinel 实例将会向其他 sentinel 间歇性(一秒)发送”is-master-down-by-addr “指令并获取响应信息, 如果足够多的 sentinel 实例检测到 master 处于 SDOWN,那么此时当前 sentinel 实例标记 master 为 ODOWN…其他 sentinel实例做同样的交互操作.配置项”sentinel monitor
“,如果检测到 master 处于 SDOWN 状态的slave 个数达到,那么此时此 sentinel 实例将会认为 master 处于 ODOWN;
  d.每个 sentinel 实例将会间歇性(10 秒)向 master 和 slaves 发送”INFO”指令,如果 master失效且没有新 master 选出时,每 1 秒发送一次”INFO”;”INFO”的主要目的就是获取并确认当前集群环境中 slaves 和 master 的存活情况;
  经过上述过程后,所有的 sentinel 对 master 失效达成一致后,开始 failover。

2) Sentinel 与 slaves”自动发现”机制
  在 sentinel 的配置文件中(local-sentinel.conf),都指定了 port,此 port 就是 sentinel 实例侦听其他 sentinel 实例建立链接的端口.在集群稳定后,最终会每个 sentinel 实例之间都会建立一个 tcp 链接,此链接中发送”PING”以及类似于”is-master-down-by-addr”指令集,可用用来检测其他 sentinel 实例的有效性以及”ODOWN”和”failover”过程中信息的交互。
  在 sentinel 之间建立连接之前,sentinel 将会尽力和配置文件中指定的 master 建立连接。sentinel 与 master 的连接中的通信主要是基于 pub/sub 来发布和接收信息,发布的信息内容包括当前 sentinel 实例的侦听端口。

3)Leader 选举
  其实在 sentinels 故障转移中,仍然需要一个”Leader”来调度整个过程:master 的选举以及 slave 的重配置和同步。当集群中有多个 sentinel 实例时,如何选举其中一个 sentinel 为leader 呢?

  redis2.8.7的选举有两个条件,首先是要下面的条件过滤掉一些节点

使用如下条件筛选备选node:
1、slave节点状态处于S_DOWN,O_DOWN,DISCONNECTED的除外
2、最近一次ping应答时间不超过5倍ping的间隔(假如ping的间隔为1秒,则最近一次应答延迟不应超过5秒,redis sentinel默认为1秒)
3、info_refresh应答不超过3倍info_refresh的间隔(原理同2,redis sentinel默认为10秒)
4、slave节点与master节点失去联系的时间不能超过( (now-master->s_down_since_time) + (master->down_after_period * 10))。总体意思是说,slave节点与master同步太不及时的(比如新启动的节点),不应该参与被选举。
5、Slave priority不等于0(这个是在配置文件中指定,默认配置为100)。 从备选node中,按照如下顺序选择新的master
1、较低的slave_priority(这个是在配置文件中指定,默认配置为100)
2、较大的replication offset(每个slave在与master同步后offset自动增加)
3、较小的runid(每个redis实例,都会有一个runid,通常是一个40位的随机字符串,在redis启动时设置,重复概率非常小)
4、如果以上条件都不足以区别出唯一的节点,则会看哪个slave节点处理之前master发送的command多,就选谁。
我们期望有足够多的sentinel实例, 这样能够确保当leader失效时, 能够选举某个sentinel为 leader,以便进行 failover。如果 leader 无法产生,比如较少的 sentinels 实例有效,那么failover 过程将无法继续。

4)failover 过程
  在 Leader 触发 failover 之前,首先 wait 数秒(随即 0~5),以便让其他 sentinel 实例准备和调整,如果一切正常,那么 leader 就需要开始将一个 salve 提升为 master,此 slave 必须为状态良好(不能处于 SDOWN/ODOWN 状态)且权重值最低(redis.conf 中)的, 当 master 身份被确认后,开始 failover。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1793040