Redis高可用之哨兵模式(第二部分)

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介: Redis高可用之哨兵模式(第二部分)

引言

接上一篇,今天我们来聊一聊Redis的高可用的第二个解决方案:哨兵模式。

一、Redis哨兵模式

哨兵模式(sentinel)是Redis提供的高可用的解决方案之一。由一个或者多个sentinel示例组成的sentinel系统,可以监听任意数量的主服务器,以及这些服务器属下的所有从服务器,并在被监视的主服务进入下线状态时,自动从该主服务器属下的从服务器中选出新的主服务器,对外提供服务。

1.1 哨兵模式优缺点
  • 优点:在主从复制的基础上实现了主节点的自动故障转移
  • 缺点:部署麻烦、数据可能丢失、扩展麻烦、主从迁移很慢(大概在几十秒),实际项目中大部分用的是集群的解决方案

sentinel本质上是一个运行在特殊模式下的Redis服务器。不过,因为sentinel不存储业务数据,只用来监视数据节点的状态,所以它的代码和普通Redis服务器是不同的。比如:服务的端口和命令表的不同。

sentinel使用的端口及命令表

#define REDIS_SENTINEL_PORT 26379
// src/sentinel.c
struct redisCommand sentinelcmds[] = {
    {"ping",pingCommand,1,"fast @connection",0,NULL,0,0,0,0,0},
  ...
    {"info",sentinelInfoCommand,-1,"random @dangerous",0,NULL,0,0,0,0,0},
  ...
};

二、如何使用哨兵模式

2.1 启动哨兵模式

使用命令启动sentinel

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

假设有如下配置文件:表示该sentinel监视了两个主服务器master1和master2 ,该sentinel会创建如下图的两个sentinelRedisInstance 实例结构,结构源码及各个字段的功能描述,我们会在源码分析部分详细展开,这里不做赘述:

####################
# master1 configure #
####################
sentinel monitor master1 127.0.0.1 6379 2
sentinel down-after-milliseconds master1 30000
sentinel parallel-sync master1 1
sentinel failover-timeout master1 900000
####################
# master2 configure #
####################
sentinel monitor master2 127.0.0.1 2345 5
sentinel down-after-milliseconds master2 50000
sentinel parallel-sync master2 5
sentinel failover-timeout master2 450000

2.2 哨兵节点获取被监听对象信息

在加载完配置文件,sentinel获取到要监视的主服务器,会为每个主服务器都创建两个异步的网络连接:命令连接和订阅连接。前者主要用来向主服务器发送命令和接收命令回复,后者用来专门订阅主服务的__sentinel__:hello 频道,这个频道的作用主要用来感知和通知其他sentinel或自身sentinel的存在。

Redis是如何区分一个实例是主服务器、从服务器和sentinel的?

主要看flags字段,SRI_MASTER、SRI_SLAVE、SRI_SENTINEL

2.2.1 获取主服务器信息及下属所有从服务器。

创建完网络连接,sentinel和主服务器就可以通信了。sentinel默认以每10秒一次的频率,通过命令连接想被监视的主服务器发送INFO命令,通过INFO命令的回复获取主服务器的当前信息。这些信息包括两方面:(1)主服务器自身的信息,如自己的run_id 和角色(主/从/sentinel);(2)该主服务器属下所有的从服务器的信息(ip、port 在线状态、复制偏移等);

对于获取的从服务器的信息会被用来更新所属主服务器示例结构的slaves字典,这个字典保存主服务器所有的从服务器信息,字典的key是sentinel自动设置的名字(格式为:ip+port),字典的值为从服务器对应的实例结构。sentinel在分析从服务器的信息时,如果存在,则更新该实例结构,如果从服务器的实例不存在,则说明该从服务器是新发现的,会在slaves字典中为这个从服务器创建新的实例,并且为该从服务器创建两个异步连接:命令连接和订阅连接。在命令连接创建完成后,sentinel默认会以10秒一次的频率向从服务器发送INFO命令,获取从服务器的信息,类似下面的回复:

run_id:32be0699dd27b410fc790da3a6fab17f97899f  //从服务器的运行id
...
# Replication
role:slave                    //从服务器的角色role
master_host:127.0.0.1         //主服务器的ip
master_port:6379              //主服务器的port
master_link_status:up         //主从服务器的连接状态
slave_repl_offset:11887       //从服务器的复制偏移量
slave_priority:100            //从服务器的优先级
# other sectiorns
...
2.2.2 向主服务器和从服务器发送信息

sentinel默认会以每两秒一次的频率,通过命令连接向所有被监视的主、从服务器的__sentinel_:hello频道发送以下命令:

PUBLISH __sentinel:hello "<s_ip>,<s_port>,<s_run_id>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>"

命令说明:

所有以s_开头的参数记录的是sentinel本身的信息;以m_开头的参数表示的是主服务器的信息,如果sentinel监视的是主服务器,那么这些参数记录的就是主服务器的信息,如果监视的是从服务器,这些参数记录的是从服务器正在复制的主服务器的信息。

这个命令有什么用呢?当sentinel与一个主服务器或者从服务器建立起订阅连接后,sentinel就会通过订阅连接,向服务器发送:

SUBSCRIBE _sentinel:hello

也就是说监视了同一主服务器sentinel都订阅了该频道。当一个sentinel往该频道里发送消息是,所有的sentinel都能收到该条消息,包括自身。收到消息的sentinel会根据s_runid来判断是不是自己发出的消息,如果是自己发的就丢弃;如果是别的sentinel发的,更新相应的主服务器实例结构,具体来说就是:收到消息的sentinel会在自己的sentinel状态的masters字典中查找对应的主服务器实例,再在主服务的实例对应的sentinels字典中查找有没有发消息的sentinel的信息,如果有就更新sentinel的实例结构,如果没有说明该sentinel是刚开始监听主服务器的sentinel,为其创建sentinel结构添加到主服务器的sentinels字典中。该字典保存所有监视同一服务器的sentinel。

sentinel可以通过接收频道的信息来感知其他sentinel的存在,并通过发送频道信息让其他sentinel知道自己的存在。

当sentinel通过频道信息发现了一个新的sentinel时,不仅会在自己的sentinels字典中创建相应的实例,还会创建连向新sentinel的命令连接,而新的sentinel同样会创建连向这个sentinel的命令连接。sentinel之间通过命令连接进行接下来的一系列操作(主客观下线、选举等)。

三、sentinel工作流程

哨兵模式的工作流程可以分为五个步骤:主观下线、客观下线、哨兵选举、从库选主和故障转移

3.1 主观下线

主观下线:就是某个sentinel认为某个实例下线了,就是单纯的“我以为”,还要经过其他的sentinel的认同,才会进入“客观下线”,也就是大家都认为。

sentinel默认会以每秒一次的频率向所有与自己创建了命令连接的实例(主从、其他sentinel)发送PING命令,通过返回值来判断某个实例是否下线。在配置文件中有个参数down-after-milliseconds,这个参数指定sentinel判断一个实例主观下线的时间长度。如果一个实例在down-after-milliseconds毫秒内,连续想sentinel返回了无效回复,sentinel就会修改该实例对应的flags子弹,打开SRI_S_DOWN标识,以此标记这个实例进入主观下线状态。

回复结果:

  • 有效回复: +PONG -LOADING -MASTERDOWN 三种;
  • 无效回复:除有效回复外的所有回复

假设用户配置如下:

sentinel monitor master 127.0.0.1 6379 2
sentinel down-after-milliseconds master 50000

这50000毫秒不仅是sentinel判断master进入主观下线的标准,也会是sentinel判断master属下所有从服务器和所有监视该master的其他sentinel进入主观下线的标准。

注意:多个sentinel设置的主观下线时长可能不同,需要查看具体的配置文件。

3.2 客观下线

当一个sentinel认为一个主服务器为主观下线后,为了确保这个主服务器是不是真的下线了,需要向监视了这个主服务器的其他sentinel询问。当收到足够数量的下线信息后,sentinel会将主服务器判定为客观下线,设置flags的SRI_O_DOWN标识,并准备对主服务器进行故障转移操作。

通过发送 SENTINEL is-mater-down-by-addr 命令询问其他sentinel

SENTINEL is-mater-down-by-addr <ip> <port> <current_epoch> <run_id>

当认为主服务器已经下线状态的sentinel的数量(包括自己),超过sentinel配置中设置的quorum参数的值,那么该sentinel就任务主服务器已经进入客观下线。

// quorum 参数设置
sentinel monitor master 127.0.0.1 6379 2

不同的sentinel判断客观下线的条件也可能不同。

3.3 领头sentinel的选举

选举规则

  • 监视同一个主服务器的任意一个sentinel都有可能成为领头sentinel。
  • 每次选举完领头sentinel后。不论选举是否成功,所有sentinel的配置纪元会自增1。配置纪元实际上就是个计数器,没什么特别的;
  • 在一个配置纪元里,所有的sentinel都有一次能将某个sentinel设置为局部领头sentinel的机会,且机会只有一次,先到先得。
  • 如果在给定时间内,没有一个sentinel被选为领头sentinel,那么各个sentinel会在一段时间后,再次进行选举。配置纪元就是选举的任期。

选举流程

  • 当一个sentinel(源sentinel)向另一个sentinel(目标sentinel)发送 SENTINEL is-master-down-by-addr 命令,并且命令中的参数不是*,而是自己的run_id,表示源sentinel要求目标sentinel将自己设置为它的局部领头sentinel。
  • 目标sentinel在收到SENTINEL is-master-down-by-addr 命令后,回复中的leader_runid 参数和leader_epoch 参数分别记录自己的局部领头sentinel的运行ID和配置纪元;
  • 源sentinel在收到消息后,检查leader_epoch 是不是和自己的配置纪元一致,如果一致,取出 leader_runid 与自己的 run_id 比较,如果一致,表示目标sentinel 同意选自己为局部领头sentinel,如果不一致,说明目标sentinel已经选别的sentinel为局部领头sentinel了
  • 如果某个sentinel被半数以上的sentinel设置为局部领头sentinel,那么这个局部领头sentinel就称为领头sentinel。
3.4 从库选主和故障转移

在选举产生领头sentinel后,领头的sentinel将对已下线的主服务器执行故障转移操作,该操作分为三步:

  1. 在已下线的主服务器属下的从服务器里选一个服务器,将其转为主服务器(SLAVEOF no one)
  2. 让其他从服务器改复制新的主服务器
  3. 将已下线的主服务器设置为新的主服务器的从服务器,当旧的主服务器重新上线时就会称为新的主服务器的从服务器。

在发送SLAVEOF no one命令后,领头的sentinel会以每秒一次的频率发送INFO,检查角色(role)信息,直至变为master,就顺利将从服务器升级为主服务器了。

修改从服务器的复制目标

slaveof   让从服务器复制新的额主服务器。

四、哨兵模式源码分析

sentinelState 定义:

/* Main state. */
struct sentinelState {
    char myid[CONFIG_RUN_ID_SIZE+1]; /* 哨兵的id */
    uint64_t current_epoch;         /* 当前纪元,用来实现故障转移 */
    dict *masters;      // 记录所有被哨兵监视的主服务器的信息,字典的键是主服务器的名字,值是该服务器对应的sentinelRedisInstance服务器实例
    int tilt;           /*是否进入到tilt模式 */
    int running_scripts;    /* 当前运行的脚本的数量*/
    mstime_t tilt_start_time;       /* 进入tilt的时间 */
    mstime_t previous_time;         /* 最后一次执行时间处理器的时间 */
    list *scripts_queue;            /* 保存用户所有要运行的脚本*/
    char *announce_ip;  /* 如果不为NULL,表示与其他sentinel通信的ip地址*/
    int announce_port;  /* 如果不为0,表示与其他sentinel通信的port端口 */
    unsigned long simfailure_flags; /*simulation 失败标志 */
    int deny_scripts_reconfig;  // 是否允许sentinel在运行时通过set xx改变脚本的路径
    // auth 命令使用的用户名和密码,用于验证
    char *sentinel_auth_pass;    /* Password to use for AUTH against other sentinel */
    char *sentinel_auth_user;    /* Username for ACLs AUTH against other sentinel. */
    // 支持域名,前提是设置好DNS
    int resolve_hostnames;       /* Support use of hostnames, assuming DNS is well configured. */
    int announce_hostnames;      /* Announce hostnames instead of IPs when we have them. */
} sentinel;
4.1 什么是TILT?

TITL:因为sentinel依赖本机时间驱动,如果系统时间出问题,或者因为进程阻塞导致的时间函数延迟调用。这时再去参与集群逻辑会出现不正确的决策。因此如果当前时间和上一次执行时间差为负值或者超过2s,该节点会进入TILT模式。

4.2 sentinelRedisInstance结构定义:

每一个sentinelRedisInstance表示一个被sentinel监视的Redis服务器实例。这个实例可以使主服务器、从服务器或者另一个sentinel实例。

typedef struct sentinelRedisInstance {
  // 标识值,记录了实例的类型,以及该实例的当前状态 在sentinel进行故障转移时用到,
    int flags;      /* See SRI_... defines */
    // 实例的名字
  // 主服务器的名字由用户在配置文件中设置
  // 从服务器以及 Sentinel 的名字由 Sentinel 自动设置
  // 格式为 ip:port ,例如 "127.0.0.1:26379"
    char *name;     /* Master name from the point of view of this sentinel. */
    // 实例的运行 ID 服务器初始化自动生成
    char *runid;    /* Run ID of this instance, or unique ID if is a Sentinel.*/
    uint64_t config_epoch;  /* 配置纪元,用于实现故障转移 */
    sentinelAddr *addr; /* 实例的地址 ip+port*/
    // 连接状态描述
    instanceLink *link; /* Link to the instance, may be shared for Sentinels. */
    // 最后一次通过发布、订阅频道发送问候信息的时间
    mstime_t last_pub_time;   /* Last time we sent hello via Pub/Sub. */
    // 最后一次从这个sentinel的发布订阅频道收到问候信息的时间。只有当设置了SRI_SENTINEL才会使用
    mstime_t last_hello_time; /* Only used if SRI_SENTINEL is set. Last time
                                 we received a hello from this Sentinel
                                 via Pub/Sub. */
    // 最后一次恢复 is-master-down 命令的时间
    mstime_t last_master_down_reply_time; /* Time of last reply to
                                             SENTINEL is-master-down command. */
    // 
    mstime_t s_down_since_time; /* 主观下线时间. */
    mstime_t o_down_since_time; /* 客观下线时间. */
    mstime_t down_after_period; /* 实例多少毫秒没有响应会被判定为主观下线 */
    // 从实例获取INFO命令回复的时间
    mstime_t info_refresh;  /* Time at which we received INFO output from it. */
    dict *renamed_commands;     /* Commands renamed in this instance:
                                   Sentinel will use the alternative commands
                                   mapped on this table to send things like
                                   SLAVEOF, CONFING, INFO, ... */
    /* Role and the first time we observed it.
     * This is useful in order to delay replacing what the instance reports
     * with our own configuration. We need to always wait some time in order
     * to give a chance to the leader to report the new configuration before
     * we do silly things. */
    // 实例的角色
    int role_reported;
    mstime_t role_reported_time;
    // 从服务器的主服务器地址最后一次变更的时间
    mstime_t slave_conf_change_time; /* Last time slave master addr changed. */
    /* Master specific. */
    dict *sentinels;    /* 监视了同一个主服务的其他sentinel */
    // 如果该服务器时主服务器,则slaves保存该主服务下面所有的从服务器
    dict *slaves;       /* Slaves for this master instance. */
    //判断这个实例为客观下线所需的支持投票数量
    unsigned int quorum;/* Number of sentinels that need to agree on failure. */
    // 在执行故障转移时,可以同时对新的主服务器进行同步的从服务器数量
    int parallel_syncs; /* How many slaves to reconfigure at same time. */
    // 主从复制的用户和密码校验
    char *auth_pass;    /* Password to use for AUTH against master & replica. */
    char *auth_user;    /* Username for ACLs AUTH against master & replica. */
    /* Slave specific. */
    // 主从复制断开的时间
    mstime_t master_link_down_time; /* Slave replication link down time. */
    // 从服务器的优先级
    int slave_priority; /* Slave priority according to its INFO output. */
    int replica_announced; /* Replica announcing according to its INFO output. */
    // 执行故障转移操作时,从服务器发送 SLAVEOF <new-master> 命令的时间
    mstime_t slave_reconf_sent_time; /* Time at which we sent SLAVE OF <new> */
    // 如果该实例是从服务器,则master保存它的主服务器的实例地址
    struct sentinelRedisInstance *master; /* Master instance if it's slave. */
    // INFO 命令的回复中记录的主服务器 IP 和 PORT
    char *slave_master_host;    /* Master host as reported by INFO */
    int slave_master_port;      /* Master port as reported by INFO */
    // INFO 命令中回复的主服务的连接状态
    int slave_master_link_status; /* Master link status as reported by INFO */
  // 从服务器的复制偏移量
    unsigned long long slave_repl_offset; /* Slave replication offset. */
    /* Failover */
    // 如果这是一个主服务器实例,那么 leader 将是负责进行故障转移的 Sentinel 的运行 ID 。
  // 如果这是一个 Sentinel 实例,那么 leader 就是被选举出来的领头 Sentinel 。
  // 这个域只在 Sentinel 实例的 flags 属性的 SRI_MASTER_DOWN 标志处于打开状态时才有效。
    char *leader;       /* If this is a master instance, this is the runid of
                           the Sentinel that should perform the failover. If
                           this is a Sentinel, this is the runid of the Sentinel
                           that this Sentinel voted as leader. */
    // 领头的纪元
    uint64_t leader_epoch; /* Epoch of the 'leader' field. */
    // 当前执行中的故障转移的纪元
    uint64_t failover_epoch; /* Epoch of the currently started failover. */
    // 故障转移操作的当前状态
    int failover_state; /* See SENTINEL_FAILOVER_STATE_* defines. */
    // 故障改变的时间
    mstime_t failover_state_change_time;
    // 最后一次故障转移的时间
    mstime_t failover_start_time;   /* Last failover attempt start time. */
    // SENTINEL failover-timeout <master-name> <ms> 选项的值
  // 刷新故障迁移状态的最大时限
    mstime_t failover_timeout;      /* Max time to refresh failover state. */
    mstime_t failover_delay_logged; /* For what failover_start_time value we
                                       logged the failover delay. */
  // 指向被提升为新主服务器的从服务器的指针
    struct sentinelRedisInstance *promoted_slave; /* Promoted slave instance. */
    /* Scripts executed to notify admin or reconfigure clients: when they
     * are set to NULL no script is executed. */
    char *notification_script;
    char *client_reconfig_script;
    sds info; /* cached INFO output */
} sentinelRedisInstance;


推荐一个零声学院免费教程,个人觉得老师讲得不错,分享给大家:[Linux,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK等技术内容,点击立即学习:

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
3月前
|
NoSQL 关系型数据库 MySQL
Redis高可用之主从复制架构(第一部分)
Redis高可用之主从复制架构(第一部分)
|
3月前
|
监控 负载均衡 NoSQL
Redis之哨兵模式
Redis之哨兵模式
|
3月前
|
机器学习/深度学习 NoSQL Redis
Redis高可用之集群架构(第三部分)
Redis高可用之集群架构(第三部分)
|
3月前
|
存储 监控 NoSQL
|
3月前
|
监控 NoSQL 算法
Redis之哨兵模式
【1月更文挑战第8天】哨兵模式说白点就是:自动选举老大的模式。
190 6
|
2月前
|
存储 NoSQL Java
面试官:Redis如何保证高可用?
面试官:Redis如何保证高可用?
76 2
面试官:Redis如何保证高可用?
|
3月前
|
监控 NoSQL 程序员
Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理
Redis 高可用篇:你管这叫 Sentinel 哨兵集群原理
77 5
|
3月前
|
存储 负载均衡 NoSQL
Redis 高可用篇:你管这叫主从架构数据同步原理?
Redis 高可用篇:你管这叫主从架构数据同步原理?
237 5
|
3月前
|
缓存 监控 NoSQL
Redis的哨兵模式是什么?它的作用是什么?
Redis的哨兵模式是什么?它的作用是什么?
163 0
|
3月前
|
NoSQL 算法 Redis
Redis哨兵模式原理
Redis哨兵模式原理
46 0