深入理解Redis—Sentinel哨兵模式

Sentinel(哨兵)是Redis的高可用性解决方案:由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替已下线的主服务器继续处理命令请求;

启动并初始化:

      启动一个Sentinel的命令:redis-sentinel  /path/to/your/sentinel.conf      或redis-server  /path/to/your/sentinel.conf  --sentinel 两命令效果相同。当一个Sentinel启动时,会执行以下步骤:

  • 初始化服务器 ;
  • 将普通Redis服务器使用的代码替换成Sentinel专用代码;
  • 初始化Sentinel状态;
  • 根据给定的配置文件,初始化Sentinel的监视主服务器列表;
  • 创建连向主服务器的网络连接;

  1. 初始化服务器:
    1. Sentinel的本质是运行在特殊模式下的Redis服务器,但与普通服务器在初始化时会载入RDB/AOF文件不同,Sentinel服务器不使用数据库,所以Sentinel初始化时并不会载入以上文件;
  2. 使用Sentinel专用代码
    1. 普通Redis服务器使用6379作为监听端口号;Sentinel服务器使用26379作为监听端口号;
    2. 根据命令表可知,Sentinel模式下的服务器没有get/set/setnx等命令,所以Sentinel模式下的服务器无法对数据库进行操作;客户端可对Sentinel执行的命令:PING、SENTINEL、INFO、SUNBSRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE
  3. 初始化Sentinel状态
    1. 服务器会初始化一个sentinel.c/sentinelState结构(简称“Sentinel状态”),该结构保存了服务器中所有和Sentinel功能有关的状态;、
  4. 初始化Sentinel状态的master属性
    1. Sentinel状态中的masters属性是一个字典,该字典中记录了所有被Sentinel监视的主服务器的相关信息:
      • 字典的键:被监视主服务器的名字;
      • 字典的值:被监视主服务器对应的sentinel.c/sentinelRedisInstance结构;
    2. sentinelRedisInstance结构,代表一个被Sentinel监视的Redis服务器实例(简称“实例结构”),该实例既可以是主服务器也可以是从服务器或者其他Sentinel;
    3. 对Sentinel状态的初始化将引发对masters字典的初始化,而masters字典的初始化是根据被载入的Sentinel配置文件来进行的。深入理解Redis—Sentinel哨兵模式_第1张图片

     

  5. 创建连向主服务器的网络连接:
    1. 初始化的最后一步是创建连向被监视主服务器的网络连接,Sentinel将成为主服务器的客户端,它可以向主服务器发送命令,并从命令回复中获取相关的信息。
    2. 对于每个被Sentinel监视的主服务器,Sentinel会创建两个连向主服务器的异步网络连接:
      • 命令连接:专门用于向主服务器发送命令,并接受命令回复;
      • 订阅连接:专门用于订阅主服务器的_sentinel_:hello频道;

补充:为什么有两个连接?——在Redis目前的发布订阅功能中,被发送的信息都不会保存在Redis服务器里面,若发送信息时,想要接受信息的客户端离线,那么该客户端将会丢失这条信息。因此,为了不丢失__sentinel__: hello 频道的任何信息,Sentinel必须专门用一个订阅连接来接收该频道的消息; 另一方面,Sentinel还必须向主服务器发送命令,以此与主服务器进行通信,所以Sentinel还必须向主服务器创建命令连接。

获取主服务器信息

      Sentinel默认每10秒通过命令连接向其监视的主服务器发松INFO命令,并通过命令回复分析主服务器状态。

  1. INFO命令回复可解析出两方面信息:
    1. 主服务器本身信息:主服务器自身的runid,以及服务器角色role信息;
    2. 主服务器属下所有从服务器信息:包括了主服务器属下所有从服务器的ip地址、端口号等信息(通过该信息,Sentinel无需用户提供从服务器的信息,即可自动发现)

根据run_id和role域所记录的信息,Sentinel将对主服务器的实例结构(sentinelRedisInstance结构)进行相关信息更新;

命令回复中返回的从服务器信息,会被用于更新主服务器实例结构的slaves字典,该字典记录了主服务器属下所有从服务器的名单信息;

注:主服务器实例结构的name属性值用户通过Sentinel配置文件设置的,而从服务器实例结构的name属性值则是Sentinel根据从服务器的IP地址和端口号自动设置的;深入理解Redis—Sentinel哨兵模式_第2张图片

 

获取从服务器信息

      当Sentinel发现自身所监视的主服务器有新的从服务器时,不仅会为其创建相应的实例结构,还会创建连接到这个从服务器的命令连接以及订阅连接;

      同样,Sentinel也会每10秒向从服务器发送INFO命令,并通过命令回复分析从服务器的相关信息,并更新自身对从服务器的认知;

向主服务器和从服务器发送信息

      默认情况下,Sentinel会每2秒一次通过命令连接向所有被监视的主服务器和从服务器的 __sentinel__:hello频道发送PUBLISH...命令,该命令中包括了Sentinel自身的相关信息以及目标主服务器的相关信息(若目标为从服务器,则记录的是从服务器正在复制的主服务器信息);

接收来自主服务器和从服务器的频道信息

      当Sentinel与一个主服务器或从服务器建立起订阅连接之后,Sentinel就会通过订阅连接向服务器发送:SUBSCRIBE  __sentienl__:hello命令,即为订阅该频道,该订阅状态会一直持续到Sentinel与服务器断开位置。

      对于每个与Sentinel连接的服务器,Sentinel既通过命令连接向服务器的 __sentinel__:hello频道发送信息,又通过订阅连接从服务器的该频道接收信息;

      对于监视同一个服务器的多个Sentinel来说,一个Sentinel发送的信息会被其他Sentinel接收到,这些信息会被用于更新其他Sentinel对源Sentinel以及被共同监视的服务器的认知。(注:源Sentinel也会收到自身所发送的信息,通过比对运行id,会进行消息的舍弃)

更新sentinels字典

      Sentinel为主服务器创建的实例结构中的sentinels字典保存了所有监视该主服务器的Sentinel信息;

当目标Sentinel接收到了某个源Sentinel的信息时,会从信息中提取出主服务器,以及源Sentinel的相关信息;目标Sentinel会在自身的Sentinel状态中的masters属性中比对主服务器信息,查看是否存在该主服务器,若存在,则会对该主服务器实例结构的sentinels字典中的源Sentinel信息进行更新。

监视同一个主服务器的多个Sentinel可以自动发现对方,无需用户提供各个Sentinel的地址信息。

创建连向其他Sentinel的命令连接

      监视同一个主服务器的Sentinel之间会互相创建连向对方的命令连接,以通过互相发送命令请求而达到信息交换的目的;Sentinel之间只会创建命令连接,而不会创建订阅连接(因为Sentinel需要通过接收主服务器或从服务器发来的频道信息来发现未知的新Sentinel,所以才需要建立订阅连接)

检查主观下线状态

      默认情况下,Sentinel会以每秒一次的频率向所有与它建立了命令连接的实例(主、从服务器、其他Sentinel)发送PING命令,并通过PING命令的回复来判断实例是否在线。

      有效命令回复:+PONG、-LOADING、-MASTERDOWN三种之中的任意一种;

      无效命令回复:除以上三种以外的其他回复,或在指定时间内没有任何回复;

Sentinel配置文件中的down-after-milliseconds选项指定了Sentinel判断实例进入主观下线所需的时间长度:若一个实力在down-after-milliseconds毫秒内,连续向Sentinel返回无效回复,那么Sentinel判断此实例“主观下线”,并在该实例结构中的flag属性打开SRI_S_DOWN标识。(注:该下线时长被用于判定所有与源Sentinel相关联的实例,多个Sentinel对该时长的设置可能不同

检查客观下线状态

      当一个Sentinel判定某个主服务器为主观下线状态时,会向其他同样监视该主服务器的Sentinel确认该主服务器是否进入“客观下线”状态,若判定该主服务器进入“客观下线”状态,则对其进行故障转移;

  1. Sentinel向其他监视该主服务器的Sentinel发送SENTINEL  is-master-down-by-addr       命令询问其他Sentinel是否同意主服务器进入下线状态;

注:ip、port为主服务器的ip地址以及端口号;current_epoch为Sentinel当前的配置纪元,用于选举零头Sentinel;runid当为“ * ”时,则仅仅用于检测主服务器的客观下线状态,若为Sentinel的运行id则用于选举领头Sentinel;

  1. 接受SENTINEL  is-master-down-by-addr命令:当目标Sentinel接收到源Sentinel发送的该命令时,会通过解析该命令请求中各个参数(ip、port等)来检查目标服务器是否已下线,并返回一条包含三个参数的Multi Bulk作为命令回复:

Notes:down_state意为,对目标主服务器的检查结果,1 则代表主服务器已下线,0 则代表主服务器未下线;leader_runid意为,“*”则用于检测主服务器的下线状态,“运行id号”则用于选举领头Sentinel;leader_epoch意为,该值总在leader_runid不为“*”时有效,若为“*”则该值总为0;

  1. 接收SENTINEL  is-master-down-by-addr命令的回复:根据其他Sentinel发回的该命令的回复,源Sentinel将统计有多少Sentinel同意主服务器已下线,当该数量达到配置中设置的quorum参数的值时,源Sentinel就会判定该主服务器已经进入客观下线状态;

注:不同Sentinel配置中的quorum值可能会设置的不同,即对于监视同一个主服务器的Sentinel判定主服务器进入客观下线的标准可能不同;

选举领头Sentinel

      当一个主服务器被判定为客观下线状态时,监视这个下线主服务器的各个Sentinel会进行协商选举出一个领头Sentinel,并由领头Sentinel对下线主服务器执行故障转移操作。

      选举领头Sentinel的规则:

  1. 监视同一个主服务器的所有Sentinel都有可能成为领头Sentinel;
  2. 没进行一轮领头Sentinel选举之后,不论是否选举成功,所有Sentinel的配置纪元的值都会自增一次。(配置纪元实质是一个计数器);
  3. 在一个配置纪元里面,所有Sentinel都有一次将某个Sentinel设置为局部领头Sentinel的机会,并且一旦局部领头Sentinel一旦设置,在这个配置纪元里就不能再更改;
  4. 当一个源Sentinel向某个目标Sentinel发送SENTINEL  is-master-down-by-addr命令,且命令中的runid参数不是“*”符号而是源Sentinel自身的运行ID时,这表示源Sentinel要求目标Sentinel将前者设置为后者的局部领头Sentinel;
  5. Sentinel设置局部领头Sentinel的规则是先到先得,并且一旦目标Sentinel将某个源Sentinel设置为局部领头Sentinel后,将会拒绝后续收到的所有设置要求;
  6. 目标Sentinel在接收到命令之后,会向源Sentinel返回一条命令回复,回复中的leader_runid参数和leader_epoch参数分别记录了目标Sentinel的局部领头Sentinel的运行ID和配置纪元;
  7. 源Sentinel在收到命令回复后,首先会查看回复中的leader_epoch值是否与自身相等,若相等,则进而检查leader_runid是否与自身匹配,若均一致则表示目标Sentinel已将自己设置为局部领头Sentinel;
  8. 若某个Sentinel被半数以上的其他Sentinel设置为局部领头Sentinel,则该Sentinel将成为领头Sentinel;

注:因为领头Sentinel的产生需要半数以上Sentinel的支持,且每个Sentinel在每个配置纪元里只能设置一次局部领头Sentinel,所以在一个配置纪元里,只会产生一个领头Sentinel;  若在规定时间内,没有产生领头Sentinel,那么过段时间继续选举,直到选举出来为止;

故障转移

      选举出领头Sentinel后,该领头Sentinel将对已下线的主服务器执行故障转移操作:① 在已下线的主服务器属下的所有从服务器中挑一个,并将其转换为主服务器;② 让其他从服务器改为复制新的主服务器;③ 将原已下线的主服务器改为新主服务器的从服务器;

  1. 选举出新的服务器
    1. 挑选出一个状态良好、数据完整的从服务器,向该服务器发送
      SLAVEOF  no  one命令,将该服务器转换为主服务器;
    2. 首先将已下线的主服务器的所有从服务器保存到一个列表中,过滤规则如下:
      • 删除列表中所有处于下线或者断线状态的服务器(保证列表中剩余的从服务器都是正常在线的)
      • 删除列表中所有最近五秒内没有回复过领头Sentinel的INFO命令的从服务器(保证列表中剩余的从服务器都是最近成功通信过的);
      • 删除所有与已下线主服务器连接断开超过down-after-milliseconds * 10毫秒的从服务器(down-after-milliseconds选项指定了判断主服务器下线所需的时间,删除这些从服务器则可以保证列表中剩余的从服务器没有过早地与主服务器断开连接,即剩余的从服务器都是保存数据较新的)
      • 之后,领头Sentinel将根据从服务器的优先级,对列表中剩余的从服务器进行排序,选出优先级最高的从服务器。
      • 若存在多个具有相同最高优先级的从服务器,则领头Sentinel将按照从服务器的复制偏移量进行排序,并选出偏移量最大的从服务器;
      • 最后,若存在多个优先级最高、复制偏移量最大的从服务器,那么领头Sentinel将按照运行ID对这些从服务器进行排序,并选出其中运行ID最小的从服务器;
    3. 当领头Sentinel向挑选出的从服务器发送过SLAVEOF  no  one 命令后,便会以每秒一次的频率向该从服务器发送INFO命令(正常状态下是每10秒一次),并观察该命令的回复信息,当role属性值由原来的slave变为master时,则说明已经由从服务器升级为主服务器;
  2. 修改其余服务器的复制目标;
  3. 将旧的主服务器变为新主服务器的从服务器;

你可能感兴趣的:(redis,sentinel,服务器)