【Redis源码】集群之哨兵sentinel故障转移 (十二)

最新推荐文章于 2024-07-16 08:39:38 发布
最新推荐文章于 2024-07-16 08:39:38 发布
阅读量897 收藏
点赞数
分类专栏： Redis C++ 文章标签： redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/byxiaoyuonly/article/details/104549345
版权
C++ 同时被 2 个专栏收录
32 篇文章 6 订阅
订阅专栏
Redis
20 篇文章 3 订阅
订阅专栏

前言：

各位看官大家好，这个主题内容比较长然后接着上一章就拆成了两个部分。那么我们接着上一章内容开始说。上一章中我们说到哨兵定时器sentinelTimer它们作用。sentinelTimer方法中执行哨兵模式中的任务。包括执行定期操作比如PING、分析主服务和从服务的INFO命令、故障转移等等。那么这一章我们就先从sentinelTimer开始说起。

(一) 基本结构

1.1 sentinelTimer 定时程序

在这里插入图片描述
图中为sentinelTimer调用链路，须线部分为调用aeCreateTimeEvent注册serverCron事件。
sentinel.c 中sentinelTimer方法：

void sentinelTimer(void) {
    //检测是否需要开启sentinel TILT模式
    sentinelCheckTiltCondition();
    //对哈希表中的每个服务器实例执行调度任务
    sentinelHandleDictOfRedisInstances(sentinel.masters);
    //执行脚本命令，
    sentinelRunPendingScripts();
    //清理已经执行完脚本的进程，
    sentinelCollectTerminatedScripts();
    //kill执行时间超时的脚本
    sentinelKillTimedoutScripts();
    /*
    * 为了防止多个哨兵同时选举时故意错开定时程序执行的时间。
    */
    server.hz = CONFIG_DEFAULT_HZ + rand() % CONFIG_DEFAULT_HZ;
}

1.2 哨兵结构介绍

基本数据结构

struct sentinelState {
    char myid[CONFIG_RUN_ID_SIZE+1]; /* 哨兵ID */
    uint64_t current_epoch;         /* Current epoch. */
    dict *masters;                  /* 存储哨兵监听服务器的信息 对应一个
                                    sentinelRedisInstance 结构体指针 */
    int tilt;                       /* 判断 TILT 模式 */
    int running_scripts;            /* 当前正在执行的脚本数。 */
    mstime_t tilt_start_time;       /*  TITL 开始时间. */
    mstime_t previous_time;         /* 上次处理程序运行时间. */
    list *scripts_queue;           /* 要执行的用户脚本队列. */
    char *announce_ip;             /* IP 地址（gossip协议握手地址） */
    int announce_port;              /* 端口 （gossip协议端口） */
    unsigned long simfailure_flags; /* 故障模拟状态. */
} sentinel;

每一个哨兵都有一个sentinel结构，里面维护着多个主机连接。每个主机连接信息都维护着一个sentinelRedisInstance，通过这个结构维护着所有主机连接的关系。

sentinelRedisInstance结构信息:
typedef struct sentinelRedisInstance {
    int flags;      /* 记录哨兵类型以及实力当前状态 */
    char *name;     /* 哨兵名称格式为ip:port ，例如"127.0.0.1:26379" */
    char *runid;    /* 哨兵运行ID.*/
    uint64_t config_epoch;  /* 配置纪元，用于故障转移. */
    sentinelAddr *addr; /* 实例地址. */
     
     //...省略
     
    mstime_t s_down_since_time; /* 主观下线标记时间. */
    mstime_t o_down_since_time; /* 客观下线标记时间. */
    mstime_t down_after_period; /* 实例无响应多少毫秒之后才会被判断为主观下线（subjectively down ）,SENTINEL down-after-milliseconds 选项设定的值 */
  
    //。。。省略
    /* Master specific. */
    dict *sentinels;    /* 其他sentinels. */
    dict *slaves;       /* 这个master的slave */
    unsigned int quorum;/* 判断这个实例客观下线（objectively down ）所需的支持投票数量，SENTINEL monitor <master-name> <IP> <port> <quorum> 选项中的quorum 参数 */
    int parallel_syncs; /* 在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量，SENTINEL parallel-syncs <master-name> <number> 选项的值. */
    char *auth_pass;    /* Password to use for AUTH against master & slaves. */

    //。。。省略
    mstime_t failover_start_time;   /* 上次故障转移尝试开始时间. */
    mstime_t failover_timeout;      /* 刷新故障迁移状态的最大时间限制. SENTINEL failover-timeout <master-name> <ms> 选项的值*/
    
    //。。。省略
} sentinelRedisInstance;

在这里插入图片描述

1.3 sentinel建立网络连接

创建与被监听的master网络连接后，sentinel会成功master的客户端，它会向master发送命令。
并从master的响应中获取master的信息。对于每个被监听者的master，sentinel会向创建两个异步的网络连接。
该连接通过sentinelReconnectInstance函数创建，一个链接为commands链接。另外一个链接为Pub / Sub 连接。订阅发布会创建一个__sentinel__:hello的通道。

1.4 sentinel命令集

# 重置名字匹配正则表达式的所有master状态信息，清除之前存储的状态信息和slaves信息。PS：节点只要加入过sentinel，信息就会保存而不会自动清除  
sentinel reset <pattern>

# 用于改变关于master的配置，例如 sentinel set mymaster down-after-milliseconds 1000 ,此命令修改了当节点第一次失去连接到判定其下线所经过的时间
sentinel set <name> <option> <value>

# 告诉sentinel去监听新的master 
sentinel monitor <name> <ip> <port> <quorum>  

# 命令sentinel放弃对某个master的监听
sentinel remove <name>  

# 这个参数设置集群从判断节点挂掉，到执行故障转移操作（即重新选举master节点）的时间
sentinel failover-timeout mymaster 10000

# 获取哨兵监视某个sentinel的信息
sentinel sentinels <master-name>

# 获取sentinel监视的某个master的slaves信息
sentinel slaves <master-name>

# 获取sentinel 监视的某个 master信息
sentinel master <name>

# 获取sentinel监视所有的master信息
sentinel masters

# 询问该sentinel，该 ip，port的master是否为down状态，
# 如果该sentinel为tilt模式，会不理会这个询问，不去判断
# 该master是否为主观下线状态，直接回复正常状态。
sentinel is-master-down-by-addr <ip> <port> <current-epoch> <runid>

# 根据master名字获取到master的ip和port
sentinel get-master-addr-by-name <master-name>

# 将sentinel 状态信息写入到配置文件当中
setinel flushconfig

# 检查可投票同意master on failure的sentinel+1的个数以及相关状态
# （可用的投票个数是否大于master 的quorum，需要quorum个同意master on failure）
setinel ckquorum <name>

(二)发现故障

2.1如何确定故障

提及到确认故障，哨兵中确认故障有两种形式分为对应两种状态SRI_S_DOWN（主观下线）和SRI_O_DOWN（客观下线）。

1） 主观下线

主观下线会涉及到一个方法sentinelCheckSubjectivelyDown，图中会主观下线链路
在这里插入图片描述

void sentinelCheckSubjectivelyDown(sentinelRedisInstance *ri) {
    mstime_t elapsed = 0;

    if (ri->link->act_ping_time)
        elapsed = mstime() - ri->link->act_ping_time;
    else if (ri->link->disconnected)
        elapsed = mstime() - ri->link->last_avail_time;

    /* 检测command 连接是否被关闭 */
    if (ri->link->cc &&
        (mstime() - ri->link->cc_conn_time) >
        SENTINEL_MIN_LINK_RECONNECT_PERIOD &&
        ri->link->act_ping_time != 0 && /* Ther is a pending ping... */
        /* The pending ping is delayed, and we did not received
         * error replies as well. */
        (mstime() - ri->link->act_ping_time) > (ri->down_after_period/2) &&
        (mstime() - ri->link->last_pong_time) > (ri->down_after_period/2))
    {
        instanceLinkCloseConnection(ri->link,ri->link->cc);
    }

    /* 检测pubsub连接是否需要被关闭 
     */
    if (ri->link->pc &&
        (mstime() - ri->link->pc_conn_time) >
         SENTINEL_MIN_LINK_RECONNECT_PERIOD &&
        (mstime() - ri->link->pc_last_activity) > (SENTINEL_PUBLISH_PERIOD*3))
    {
        instanceLinkCloseConnection(ri->link,ri->link->pc);
    }

    /* 更新SRI_S_DOWN状态
     */
    if (elapsed > ri->down_after_period ||
        (ri->flags & SRI_MASTER &&
         ri->role_reported == SRI_SLAVE &&
         mstime() - ri->role_reported_time >
          (ri->down_after_period+SENTINEL_INFO_PERIOD*2)))
    {
        /* Is subjectively down */
        if ((ri->flags & SRI_S_DOWN) == 0) {
            sentinelEvent(LL_WARNING,"+sdown",ri,"%@");
            ri->s_down_since_time = mstime();
            ri->flags |= SRI_S_DOWN;
        }
    } else {
        /* Is subjectively up */
        if (ri->flags & SRI_S_DOWN) {
            sentinelEvent(LL_WARNING,"-sdown",ri,"%@");
            ri->flags &= ~(SRI_S_DOWN|SRI_SCRIPT_KILL_SENT);
        }
    }
}
  1. 检测command 连接是否被关闭；
    2.检测pubsub连接是否需要被关闭 ；
    3.更新SRI_S_DOWN状态状态，更新状态有如下两个规则：
    3.1 超过ri->down_after_period，代表超过响应时间，及ping无响应请求。该时间默认走的时SENTINEL_DEFAULT_DOWN_AFTER宏为30s。
    3.2 SLAVE上报连续时间间隔要大于ri->down_after_period+SENTINEL_INFO_PERIOD2，及（30s + 10s2），如果超过这个时间代表slave长时间连续不到master，所以视为主观下线。

2） 客观下线

说到客观下线是，我们要思考一个问题。当一台master服务已经掉线，并且已经维护自己的状态为SRI_S_DOWN。由于在哨兵集群中，ri->down_after_period值可能不一样。判断master下线的时间间隔可能不一样。所以必须去询问sentinel节点这台master服务是否下线。

void sentinelHandleRedisInstance(sentinelRedisInstance *ri) {
    //。。。省略
    /* Only masters */
    if (ri->flags & SRI_MASTER) {
        sentinelCheckObjectivelyDown(ri);
        if (sentinelStartFailoverIfNeeded(ri))
            sentinelAskMasterStateToOtherSentinels(ri,SENTINEL_ASK_FORCED);
        sentinelFailoverStateMachine(ri);
        sentinelAskMasterStateToOtherSentinels(ri,SENTINEL_NO_FLAGS);  
    }
}

在上面代码中可以看到客观下线只能master中使用。然后看一下sentinelAskMasterStateToOtherSentinels方法，该方法检测master主观下线后去询问其他sentinel。

void sentinelAskMasterStateToOtherSentinels(sentinelRedisInstance *master, int flags) {
    dictIterator *di;
    dictEntry *de;

    di = dictGetIterator(master->sentinels);
    while((de = dictNext(di)) != NULL) {
        sentinelRedisInstance *ri = dictGetVal(de);
        mstime_t elapsed = mstime() - ri->last_master_down_reply_time;
        char port[32];
        int retval;

        /* If the master state from other sentinel is too old, we clear it. */
        if (elapsed > SENTINEL_ASK_PERIOD*5) {
            ri->flags &= ~SRI_MASTER_DOWN;
            sdsfree(ri->leader);
            ri->leader = NULL;
        }

        /* 满足下列情况才可以询问其他哨兵：
         *
         * 1) 主观下线是否在进行
         * 2) Sentinel是否连接
         * 3) 我们没有在哨兵询问期内收到信息，1秒内. */
        if ((master->flags & SRI_S_DOWN) == 0) continue;
        if (ri->link->disconnected) continue;
        if (!(flags & SENTINEL_ASK_FORCED) &&
            mstime() - ri->last_master_down_reply_time < SENTINEL_ASK_PERIOD)
            continue;

        /* Ask */
        ll2string(port,sizeof(port),master->addr->port);
        retval = redisAsyncCommand(ri->link->cc,
                    sentinelReceiveIsMasterDownReply, ri,
                    "SENTINEL is-master-down-by-addr %s %s %llu %s",
                    master->addr->ip, port,
                    sentinel.current_epoch,
                    (master->failover_state > SENTINEL_FAILOVER_STATE_NONE) ?
                    sentinel.myid : "*");
        if (retval == C_OK) ri->link->pending_commands++;
    }
    dictReleaseIterator(di);
}

通过遍历维护的master->sentinels结构向其他sentinel节点发送命令：SENTINEL is-master-down-by-addr
命令格式如下：
SENTINEL is-master-down-by-addr <current_epoch> <leader_id>

命令询问其他sentinel是否同意主服务器已下线。

接受SENTINEL is-master-down-by-addr命令返回状态：
<down_state> <leader_runid> <leader_epoch>

down_state：为1代表主服务器已下线，0表示主服务器未下线。
leader_runid：领头sentinal id。
leader_epoch：领头sentinel当前投票纪元。

(三)故障转移

3.1 故障状态

当某个主节点进行故障转移时，该主节点的的故障转移状态，master->failover_state,依次会经历6个状态：
状态宏：

SENTINEL_FAILOVER_STATE_NONE 0                 /*没有故障转移在进行*/
//以下为经历的6个状态
SENTINEL_FAILOVER_STATE_WAIT_START 1           /* sentinel接手故障转移*/
SENTINEL_FAILOVER_STATE_SELECT_SLAVE 2         /* 选择slave成为master*/
SENTINEL_FAILOVER_STATE_SEND_SLAVEOF_NOONE 3   /* 发送slaveof no one给新master */
SENTINEL_FAILOVER_STATE_WAIT_PROMOTION 4       /* 等待新master升级完成，超时终止故障转移*/
SENTINEL_FAILOVER_STATE_RECONF_SLAVES 5        /* 新master升级完成后，让slaves复制新master */
SENTINEL_FAILOVER_STATE_UPDATE_CONFIG 6        /* 监视新master */

3.2 状态机

void sentinelFailoverStateMachine(sentinelRedisInstance *ri) {
    serverAssert(ri->flags & SRI_MASTER);

    if (!(ri->flags & SRI_FAILOVER_IN_PROGRESS)) return;

    switch(ri->failover_state) {
        case SENTINEL_FAILOVER_STATE_WAIT_START:
            sentinelFailoverWaitStart(ri);         //sentinel接手故障转移
            break;
        case SENTINEL_FAILOVER_STATE_SELECT_SLAVE:
            sentinelFailoverSelectSlave(ri);      //选择slave成为master
            break;
        case SENTINEL_FAILOVER_STATE_SEND_SLAVEOF_NOONE:
            sentinelFailoverSendSlaveOfNoOne(ri); //发送slaveof no one给新master
            break;
        case SENTINEL_FAILOVER_STATE_WAIT_PROMOTION:
            sentinelFailoverWaitPromotion(ri);    //等待新master升级完成，超时终止故障转移
            break;
        case SENTINEL_FAILOVER_STATE_RECONF_SLAVES:
            sentinelFailoverReconfNextSlave(ri); //新master升级完成后，让slaves复制新master
            break;
    }
}

状态机变化过程：
在这里插入图片描述

总结

1）一个哨兵结构中可以维护多个主机，包括master，slave，sentinel。
2）确定故障分为：主观下线和客观下线两种。
3）主观下线：为一段时间内ping返回无效，探测所有节点都是一致的，则为主观下线。主观下线的时间是可以配置的，以master配置维度为准。
4）客观下线：客观下线只针对于master节点，且需要master为主观下线，并通过其他sentinel节点发送SENTINEL is-master-down-by-addr询问其他节点master下线问题，达成共识的一个状态。
5) 哨兵会创建两个链接一个commands链接，一个订阅发布链接。

c-rain
关注
专栏目录
Redis学习笔记(九)：哨兵模式-监控、通知、故障转移
shiang_yan的博客
06-18 1281
简介 哨兵(sentinel)是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时，通过投票机制选择新的master并将所有slave连接到新的master 哨兵的作用： 监控：不断地检查master和slave是否正常运行，master存活检测、master与slave运行情况检测 通知(提醒)：当被监控的服务器出现问题时，向其它(哨兵间、客户端)发送通知 自动故障转移：断开master与slave连接，选取一个slave作为master，将其它slave连接到新的master，并告知
Redis高可用方案：sentinel（哨兵模式）和集群
2401_84004024的博客
04-30 785
每年转战互联网行业的人很多，说白了也是冲着高薪去的，不管你是即将步入这个行业还是想转行，学习是必不可少的。作为一个Java开发，学习成了日常生活的一部分，不学习你就会被这个行业淘汰，这也是这个行业残酷的现实。如果你对Java感兴趣，想要转行改变自己，那就要趁着机遇行动起来。或许，这份限量版的Java零基础宝典能够对你有所帮助。im 7002/redis.conf #修改端口为7002将配置文件目录拷贝到192.168.126.161上修改配置文件（端口号和ip）
Redis哨兵模式故障转移
yywuzc123的博客
06-16 923
故障转移步骤 哨兵选举领导者 选领导者的原因：只有一个sentinel节点完成故障转移 选举sentinel领导者 使用raft算法(https://raft.github.io)，大致思路： 1、每个做主观下线的sentinel节点像其他sentinel节点发送命令，要求将自己设置为领导者 2、接收到的sentinel可以同意或者拒绝 3、如果该sentinel节点发现自己的票数已经超过半数并且超过了quorum(多数派),那么它将成为领导者 4、如果此过程选举出了多个领导者，那么将等待一段时重新进行选举
聊聊Redis哨兵选举与故障转移的实现
最新发布
Hi，我是sharkchili，CSDN Java领域博客专家，开源项目JavaGuide维护人员，我想写一些有意思的东西，希望对你有帮助。
07-16 957
上一篇文章我们将哨兵主观下线的核心流程都分析完成，这一篇我们将接着之前的思路，将哨兵获取客观下线结果并结合raft协议完成哨兵leader选举完成故障转移的流程分析完成，希望对你有帮助。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。下线的看法，如果累加到的哨兵对于下线的看法大于或者等于我们配置。
Redis主从哨兵架构的故障转移
IT深耕十余载，大道之简
05-27 495
Redis主从哨兵架构的故障转移是一个确保系统高可用性的重要过程。
redis学习(肆) -- sentinel哨兵
clouderpig的博客
07-17 1165
一、定义 上一次我们讲过redis的主从复制存在一个很大的问题，就是主节点遇到故障只能手动恢复，而redis sentinel正是为了解决这一问题出现的。sentinel的核心功能就是通过对主从节点的监控实现及时发现主节点故障并自动故障转移的功能。sentinel实际上是特殊的redis节点，只是不存储数据。启动方式类似redis：./redis-sentinel sentinel.conf...
redis集群之哨兵模式sentinel
longlong6682的博客
02-29 338
一. 实验说明 1、环境说明 前提：本试验环境已经提前安装了docker和docker-compose 说明：本次部署是单机伪集群，想要部署真正的集群，需要将秒个主件拆分到各个机器上去部署，只修改ip地址 2、redis三种集群 1. 主从（主从同步原理） 2. sentinel（哨兵模式） 3. codis 详细内容请参考：https://www.cnblogs.com/xiaonq/p...
记一次官方redis cluster集群和sentinel哨兵模式结合下的节点故障切换不了的排查过程
APPLEHU09的博客
03-29 2041
环境： redis cluster集群分别在三个ip上部署了9个节点（7001-7009），三个主节点六个从节点；节点中主从数据同步确保正常；再在三个ip上部署了sentinel26379，sentinel26380，sentinel26381三个哨兵； 客户端连接： 使用ServiceStack组件 + .NET CORE 6.0；使用的哨兵+卡槽计算方式创建连接（ServiceStack官网信息说不支持redis cluster集群分区模式连接，要用redis sentinel哨兵模式创建连接，如
redis主从集群搭建及容灾部署(哨兵sentinel).pdf
11-12
哨兵系统是Redis的高可用性解决方案，负责监控、故障检测、故障转移和配置更新。在本案例中，部署了三个哨兵节点（6371、6372、6373），它们通过 gossip 协议监控主从节点的状态。当主节点出现故障时，哨兵系统会...
redis集群实现（三）集群删除节点
love coding
11-13 8096
redis集群里的节点支持动态删除，但是一般情况下不会这么做，只有在节点软硬件升级的时候才会主动让节点下线。删除节点的方式就是redis-cli客户端连接到服务器，然后执行cluster forget node-id就可以了，如果是删除一个从节点的话，集群仍然是可用状态，如果是删除一个主节点的话，集群的槽位不足，就会变成不可用状态。 下边看下我在自己的虚拟机运行的例子 127.0.0.1:
【无标题】
dandelion-xxx的博客
09-07 584
【代码】【无标题】
sentinel哨兵启动踩坑之路（持续更新）
男人要霸气的博客
08-12 3361
搭建好哨兵之后，哨兵一启动，过了30秒就会判断master sdown: [root@cache01 ~]# redis-sentinel /etc/sentinal/5000.conf 1239:X 23 May 01:40:00.457 * Increased maximum number of open files to 10032 (it was originally set to 1024). _._
springboot集成redis时，sentinel配置导致的错误
暗夜91的博客
05-16 6574
redis新手，springboot集成redis时出现了一下错误： Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled. 2019-05-16 15:05:51.455 ERROR 11828 --- [ ...
Redis Sentinel 常见问题
jcsyl_mshot的博客
05-15 1224
节点运维 节点上下线：主节点，从节点，sentinel 节点 机器下线：例如过保等情况 机器性能不足：CPU,内存等 下线： 主节点：sentinel failover (忽略主客观下线，领导选举) 从节点：临时下线还是永久下线，但是要考虑读写分离情况 上线： 主节点：sentinel failover 从节点：slave of sentinel 节点:参考其他节点启动即可 ...
填坑之路-记录Redis操作的异常QueryTimeoutException & RedisCommandTimeoutException: Command timed out after 1 min
热门推荐
汉风唐尚的博客
12-26 1万+
原始异常信息如下 org.springframework.dao.QueryTimeoutException: Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException: Command timed out after 1 minute(s) at org.springframework.data.redis.connection.lettuce.LettuceExcep
Redis开发与运维之第九章哨兵(三)--Redis Sentinel架构搭建重要点总结
搓搓那年时光静好
08-08 364
介绍如何安装和部署Redis Sentinel 部署Redis数据节点 Redis Sentinel中Redis数据节点没有做任何特殊配置,复制redis.conf文件一份 根据以下提示查找 1.启动主节点 redis-6379.conf port 6379 daemonize yes logfile "6379.log" dbfilename "dump-6379.rd...
springboot-配置多redis数据源
撸码人
09-14 773
实际工作中，redis实例可能不止一个，而是多个，所以在一些项目工程中需要配置多个redis数据源，如果采用jedis、jediscluster、shardedjedis的话就不存在配置了，可以多个实例即可，在这主要说明的是springboot+redistemplate+rediscluster的配置使用。 1、首先，pom文件提供下，方便查看相关包的依赖 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="h...
Redis 5.0.3 集群与哨兵搭建教程：Linux环境详解
- 哨兵通过监听特定端口、定期检测主节点的健康状况，如果发现主节点异常，会启动自动故障转移流程，将备份节点提升为新的主节点。 总结来说，这份文档详细地指导用户如何在Linux环境中安装Redis 5.0.3，配置集群...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值