IT数码 购物 网址 头条 软件 日历 阅读 图书馆
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
图片批量下载器
↓批量下载图片,美女图库↓
图片自动播放器
↓图片自动播放器↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
开发: C++知识库 Java知识库 JavaScript Python PHP知识库 人工智能 区块链 大数据 移动开发 嵌入式 开发工具 数据结构与算法 开发测试 游戏开发 网络协议 系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁
 
   -> 大数据 -> Redis高可用之哨兵模式(第二部分) -> 正文阅读

[大数据]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 <new_master_ip> <new_master_port> 让从服务器复制新的额主服务器。

四、哨兵模式源码分析

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;
  大数据 最新文章
实现Kafka至少消费一次
亚马逊云科技:还在苦于ETL?Zero ETL的时代
初探MapReduce
【SpringBoot框架篇】32.基于注解+redis实现
Elasticsearch:如何减少 Elasticsearch 集
Go redis操作
Redis面试题
专题五 Redis高并发场景
基于GBase8s和Calcite的多数据源查询
Redis——底层数据结构原理
上一篇文章      下一篇文章      查看所有文章
加:2022-12-25 11:16:02  更:2022-12-25 11:20:58 
 
开发: C++知识库 Java知识库 JavaScript Python PHP知识库 人工智能 区块链 大数据 移动开发 嵌入式 开发工具 数据结构与算法 开发测试 游戏开发 网络协议 系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁

360图书馆 购物 三丰科技 阅读网 日历 万年历 2024年3日历 -2024/3/29 6:27:48-

图片自动播放器
↓图片自动播放器↓
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
图片批量下载器
↓批量下载图片,美女图库↓
  网站联系: qq:121756557 email:121756557@qq.com  IT数码