redis高可用集群部署 redis集群高可用原理

Redis中为了实现高可用（High Availability，简称HA），采用了如下两个方式：

• 主从复制数据
• 采用哨兵监控数据节点的运行情况，一旦主节点出现问题由从节点顶上继续进行服务

一、主从复制

redis中主从节点复制数据有全量复制和部分复制之分。

旧版本全量复制功能的实现

全量复制使用snyc命令来实现，其流程是：

• 从服务器向主服务器发送sync命令。
• 主服务器在收到sync命令之后，调用bgsave命令生成最新的rdb文件，将这个文件同步给从服务器，这样从服务器载入这个rdb文件之后，状态就会和主服务器执行bgsave命令时候的一致。
• 主服务器将保存在命令缓冲区中的写命令同步给从服务器，从服务器执行这些命令，这样从服务器的状态就跟主服务器当前状态一致了。

旧版本全量复制功能，其最大的问题是从服务器断线重连时，即便在从服务器上已经有一部分数据了，也需要进行全量复制，这样做的效率很低，于是新版本的redis在这部分做了改进。

新版本全量复制功能的实现

Redis的持久化有RDB和AOF两种持久化方式。当服务启动的时候，我们会加载RDB或AOF文件进行数据的恢复。

Redis主从同步分两种，一种叫全量复制，就是一个节点第一次连接到master节点，需要全部的数据；另一种叫增量复制，比如已经通过过一部分数据来，再次同步只同步增量数据。

连接阶段

1. slave节点启动的时候，会在自己本地保存master节点的信息，包括master节点的ip和port。
2. slave节点内部有定时任务replicationCron，每隔1s检查是否有新的master节点要连接。

void replicaofCommand(client *c) {
    /* SLAVEOF is not allowed in cluster mode as replication is automatically
     * configured using the current address of the master node. */
    if (server.cluster_enabled) {
        addReplyError(c,"REPLICAOF not allowed in cluster mode.");
        return;
    }

    /* The special host/port combination "NO" "ONE" turns the instance
     * into a master. Otherwise the new master address is set. */
    if (!strcasecmp(c->argv[1]->ptr,"no") &&
        !strcasecmp(c->argv[2]->ptr,"one")) {
        if (server.masterhost) {
            replicationUnsetMaster();
            sds client = catClientInfoString(sdsempty(),c);
            serverLog(LL_NOTICE,"MASTER MODE enabled (user request from '%s')",
                client);
            sdsfree(client);
        }
    } else {
        long port;

        if (c->flags & CLIENT_SLAVE)
        {
            /* If a client is already a replica they cannot run this command,
             * because it involves flushing all replicas (including this
             * client) */
            addReplyError(c, "Command is not valid when client is a replica.");
            return;
        }

        if ((getLongFromObjectOrReply(c, c->argv[2], &port, NULL) != C_OK))
            return;

        /* Check if we are already attached to the specified slave */
        if (server.masterhost && !strcasecmp(server.masterhost,c->argv[1]->ptr)
            && server.masterport == port) {
            serverLog(LL_NOTICE,"REPLICAOF would result into synchronization "
                                "with the master we are already connected "
                                "with. No operation performed.");
            addReplySds(c,sdsnew("+OK Already connected to specified "
                                 "master\r\n"));
            return;
        }
        /* There was no previous master or the user specified a different one,
         * we can continue. */
        replicationSetMaster(c->argv[1]->ptr, port);
        sds client = catClientInfoString(sdsempty(),c);
        serverLog(LL_NOTICE,"REPLICAOF %s:%d enabled (user request from '%s')",
            server.masterhost, server.masterport, client);
        sdsfree(client);
    }
    addReply(c,shared.ok);
}

跟进replicationSetMaster这个深入看一下：

// 设置新主机
/* Set replication to the specified master address and port. */
void replicationSetMaster(char *ip, int port) {
    int was_master = server.masterhost == NULL;

    sdsfree(server.masterhost);
    server.masterhost = sdsnew(ip);
    server.masterport = port;
    if (server.master) {
        freeClient(server.master);
    }
    disconnectAllBlockedClients(); /* Clients blocked in master, now slave. */

    /* Update oom_score_adj */
    setOOMScoreAdj(-1);

    /* Force our slaves to resync with us as well. They may hopefully be able
     * to partially resync with us, but we can notify the replid change. */
    disconnectSlaves();
    cancelReplicationHandshake();
    /* Before destroying our master state, create a cached master using
     * our own parameters, to later PSYNC with the new master. */
    if (was_master) {
        replicationDiscardCachedMaster();
        replicationCacheMasterUsingMyself();
    }

    /* Fire the role change modules event. */
    moduleFireServerEvent(REDISMODULE_EVENT_REPLICATION_ROLE_CHANGED,
                          REDISMODULE_EVENT_REPLROLECHANGED_NOW_REPLICA,
                          NULL);

    /* Fire the master link modules event. */
    if (server.repl_state == REPL_STATE_CONNECTED)
        moduleFireServerEvent(REDISMODULE_EVENT_MASTER_LINK_CHANGE,
                              REDISMODULE_SUBEVENT_MASTER_LINK_DOWN,
                              NULL);

    server.repl_state = REPL_STATE_CONNECT;
}

接下来看一下定时任务replicationCron:

void replicationCron(void) {
    ......
    // 如果需要（EDIS_REPL_CONNECT），尝试连接主机，真正连接主机的操作在这里
    /* Check if we should connect to a MASTER */
    if (server.repl_state == REDIS_REPL_CONNECT) {
        redisLog(REDIS_NOTICE,"Connecting to MASTER %s:%d",
            server.masterhost, server.masterport);
        if (connectWithMaster() == REDIS_OK) {
            redisLog(REDIS_NOTICE,"MASTER <-> SLAVE sync started");
        }
    }
    ......
}

这里看到最核心的是connectWithMaster方法：

// connConnect 建立连接
int connectWithMaster(void) {
    server.repl_transfer_s = server.tls_replication ? connCreateTLS() : connCreateSocket();
    if (connConnect(server.repl_transfer_s, server.masterhost, server.masterport,
                NET_FIRST_BIND_ADDR, syncWithMaster) == C_ERR) {
        serverLog(LL_WARNING,"Unable to connect to MASTER: %s",
                connGetLastError(server.repl_transfer_s));
        connClose(server.repl_transfer_s);
        server.repl_transfer_s = NULL;
        return C_ERR;
    }


    server.repl_transfer_lastio = server.unixtime;
    server.repl_state = REPL_STATE_CONNECTING;
    return C_OK;
}

connection *connCreateSocket() {
    connection *conn = zcalloc(sizeof(connection));
    conn->type = &CT_Socket;
    conn->fd = -1;

    return conn;
}


/* Establish a connection.  The connect_handler will be called when the connection
 * is established, or if an error has occurred.
 *
 * The connection handler will be responsible to set up any read/write handlers
 * as needed.
 *
 * If C_ERR is returned, the operation failed and the connection handler shall
 * not be expected.
 */
static inline int connConnect(connection *conn, const char *addr, int port, const char *src_addr,
        ConnectionCallbackFunc connect_handler) {
    return conn->type->connect(conn, addr, port, src_addr, connect_handler);
}

typedef struct ConnectionType {
    void (*ae_handler)(struct aeEventLoop *el, int fd, void *clientData, int mask);
    int (*connect)(struct connection *conn, const char *addr, int port, const char *source_addr, ConnectionCallbackFunc connect_handler);
    int (*write)(struct connection *conn, const void *data, size_t data_len);
    int (*read)(struct connection *conn, void *buf, size_t buf_len);
    void (*close)(struct connection *conn);
    int (*accept)(struct connection *conn, ConnectionCallbackFunc accept_handler);
    int (*set_write_handler)(struct connection *conn, ConnectionCallbackFunc handler, int barrier);
    int (*set_read_handler)(struct connection *conn, ConnectionCallbackFunc handler);
    const char *(*get_last_error)(struct connection *conn);
    int (*blocking_connect)(struct connection *conn, const char *addr, int port, long long timeout);
    ssize_t (*sync_write)(struct connection *conn, char *ptr, ssize_t size, long long timeout);
    ssize_t (*sync_read)(struct connection *conn, char *ptr, ssize_t size, long long timeout);
    ssize_t (*sync_readline)(struct connection *conn, char *ptr, ssize_t size, long long timeout);
    int (*get_type)(struct connection *conn);
} ConnectionType;

ConnectionType CT_Socket = {
    .ae_handler = connSocketEventHandler,
    .close = connSocketClose,
    .write = connSocketWrite,
    .read = connSocketRead,
    .accept = connSocketAccept,
    .connect = connSocketConnect, // connect
    .set_write_handler = connSocketSetWriteHandler,
    .set_read_handler = connSocketSetReadHandler,
    .get_last_error = connSocketGetLastError,
    .blocking_connect = connSocketBlockingConnect,
    .sync_write = connSocketSyncWrite,
    .sync_read = connSocketSyncRead,
    .sync_readline = connSocketSyncReadLine,
    .get_type = connSocketGetType
};

同步阶段

Redis 首先会尝试部分同步，如果失败才尝试全同步。而刚刚建立连接的主从关系 需要全同步。

slave连接master后，会主动发起 PSYNC 命令，从节点会提供 master_runid 和 offset，master验证 master_runid 和 offset 是否有效？master_runid 相当于master身份验证码，用来验证salve上一次连接的master，offset 是全局积压空间数据的偏移量。

如果验证通过则进行增量同步：master返回 +CONTINUE（slave接收后会注册积压数据接收事件），master接着发送积压空间数据。

如果验证未通过则，则进行全量同步：master返回 +FULLRESYNC master_runid和offset（save接收到后并记录 master_runid 和 offset）接着启动 BGSAVE 生成 RDB 文件，BGSAVE 结束后，向从机传输，从而完成全同步。

增量同步流程图：                                                                                 全量同步流程图：

                                      

 

源码：

// 连接主机 connectWithMaster() 的时候，会被注册为回调函数
void syncWithMaster(aeEventLoop *el, int fd, void *privdata, int mask) {
    char tmpfile[256], *err;
    int dfd, maxtries = 5;
    int sockerr = 0, psync_result;
    socklen_t errlen = sizeof(sockerr);

    ......
    // 尝试部分同步，主机允许进行部分同步会返回 +CONTINUE，从机接收后注册相应的事件
    /* Try a partial resynchonization. If we don't have a cached master
     * slaveTryPartialResynchronization() will at least try to use PSYNC
     * to start a full resynchronization so that we get the master run id
     * and the global offset, to try a partial resync at the next
     * reconnection attempt. */

    // 函数返回三种状态：
    // PSYNC_CONTINUE：表示会进行部分同步，在 slaveTryPartialResynchronization()
                     // 中已经设置回调函数 readQueryFromClient()
    // PSYNC_FULLRESYNC：全同步，会下载 RDB 文件
    // PSYNC_NOT_SUPPORTED：未知
    psync_result = slaveTryPartialResynchronization(fd);
    if (psync_result == PSYNC_CONTINUE) {
        redisLog(REDIS_NOTICE, "MASTER <-> SLAVE sync: Master accepted a "
            "Partial Resynchronization.");
        return;
    }
    // 执行全同步
    ......
    // 注册读事件，回调函数 readSyncBulkPayload()， 准备读 RDB 文件
    /* Setup the non blocking download of the bulk file. */
    if (aeCreateFileEvent(server.el,fd, AE_READABLE,readSyncBulkPayload,NULL)
            == AE_ERR)
    {
        redisLog(REDIS_WARNING,
            "Can't create readable event for SYNC: %s (fd=%d)",
            strerror(errno),fd);
        goto error;
    }
    // 设置传输 RDB 文件数据的选项
    // 状态
    server.repl_state = REDIS_REPL_TRANSFER;
    // RDB 文件大小
    server.repl_transfer_size = -1;
    // 已经传输的大小
    server.repl_transfer_read = 0;
    // 上一次同步的偏移，为的是定时写入磁盘
    server.repl_transfer_last_fsync_off = 0;
    // 本地 RDB 文件套接字
    server.repl_transfer_fd = dfd;
    // 上一次同步 IO 时间
    server.repl_transfer_lastio = server.unixtime;
    // 临时文件名
    server.repl_transfer_tmpfile = zstrdup(tmpfile);
    return;
    ......
}

master节点的验证逻辑，以及触发bgsave在这里就不带大家看了。

命令传播阶段

当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致状态，同步的动作称为命令传播。master将接收到的数据变更命令发送给slave，slave接收命令后执行命令。命令传播过程中依赖网络传输，难免会出现网络中断的情况。如果是短时间的连接中断依赖第二步的部分同步就可以解决，如果长时间的连接中断就需要进行全量同步。

总结一下Redis主从同步的整个过程：

 

Redis6.0之后，出了一个新特性：reply-diskless-sync无盘复制，就是master生成的RDB文件不保存在磁盘而直接通过网络发送给slave节点。

经过主从复制后，我们Redis的集群模式可能是这样的：

 

master可负责读写服务，slave只负责读。提高了Redis的吞吐量。一切似乎看起来很美好，数据有了备份更安全，也提升了性能。

然而，如果master节点挂了呢？高可用问题依然没有得到解决。

二、哨兵机制概述

redis使用哨兵机制来实现高可用(HA)，其大概工作原理是：

• redis使用一组哨兵（sentinel）节点来监控主从redis服务的可用性。
• 一旦发现redis主节点失效，将选举出一个哨兵节点作为领导者（leader）。
• 哨兵领导者再从剩余的从redis节点中选出一个redis节点作为新的主redis节点对外服务。

以上将redis节点分为两类：

• 哨兵节点（sentinel）：负责监控节点的运行情况。
• 数据节点：即正常服务客户端请求的redis节点，有主从之分。

以上是大体的流程，这个流程需要解决以下几个问题：

• 如何对redis数据节点进行监控？
• 如何确定一个redis数据节点失效？
• 如何选择出一个哨兵领导者节点？
• 哨兵节点选择新的主redis节点的依据是什么？

以下来逐个回答这些问题。

1. 三个监控任务

哨兵节点通过三个定时监控任务监控redis数据节点的服务可用性。

info命令

每隔10秒，每个哨兵节点都会向主、从redis数据节点发送info命令，获取新的拓扑结构信息。

redis拓扑结构信息包括了：

• 本节点角色：主或从。
• 主从节点的地址、端口信息。

这样，哨兵节点就能从info命令中自动获取到从节点信息，因此那些后续才加入的从节点信息不需要显式配置就能自动感知。

向__sentinel__:hello频道同步信息

每隔2秒，每个哨兵节点将会向redis数据节点的__sentinel__:hello频道同步自身得到的主节点信息以及当前哨兵节点的信息，由于其他哨兵节点也订阅了这个频道，因此实际上这个操作可以交换哨兵节点之间关于主节点以及哨兵节点的信息。

这一操作实际上完成了两件事情： * 发现新的哨兵节点：如果有新的哨兵节点加入，此时保存下来这个新哨兵节点的信息，后续与该哨兵节点建立连接。 * 交换主节点的状态信息，作为后续客观判断主节点下线的依据。

向数据节点做心跳探测

每隔1秒，每个哨兵节点向主、从数据节点以及其他sentinel节点发送ping命令做心跳探测，这个心跳探测是后续主观判断数据节点下线的依据。

2. 主观下线和客观下线

主观下线

上面三个监控任务中的第三个探测心跳任务，如果在配置的down-after-milliseconds之后没有收到有效回复，那么就认为该数据节点“主观下线（sdown）”。

为什么称为“主观下线”？因为在一个分布式系统中，有多个机器在一起联动工作，网络可能出现各种状况，仅凭一个节点的判断还不足以认为一个数据节点下线了，这就需要后面的“客观下线”。

客观下线

当一个哨兵节点认为主节点主观下线时，该哨兵节点需要通过”sentinel is-master-down-by addr”命令向其他哨兵节点咨询该主节点是否下线了，如果有超过半数的哨兵节点都回答了下线，此时认为主节点“客观下线”。

选举哨兵领导者

当主节点客观下线时，需要选举出一个哨兵节点做为哨兵领导者，以完成后续选出新的主节点的工作。

这个选举的大体思路是：

• 每个哨兵节点通过向其他哨兵节点发送”sentinel is-master-down-by addr”命令来申请成为哨兵领导者。
• 而每个哨兵节点在收到一个”sentinel is-master-down-by addr”命令时，只允许给第一个节点投票，其他节点的该命令都会被拒绝。
• 如果一个哨兵节点收到了半数以上的同意票，则成为哨兵领导者。
• 如果前面三步在一定时间内都没有选出一个哨兵领导者，将重新开始下一次选举。

可以看到，这个选举领导者的流程很像raft中选举leader的流程。

选出新的主节点

在剩下的redis从节点中，按照以下顺序来选择新的主节点：

• 过滤掉“不健康”的数据节点：比如主观下线、断线的从节点、五秒内没有回复过哨兵节点ping命令的节点、与主节点失联的从节点。
• 选择slave-priority（从节点优先级）最高的从节点，如果存在则返回不存在则继续后面的流程。
• 选择复制偏移量最大的从节点，这意味着这个从节点上面的数据最完整，如果存在则返回不存在则继续后面的流程。
• 到了这里，所有剩余从节点的状态都是一样的，选择runid最小的从节点。

提升新的主节点

选择了新的主节点之后，还需要最后的流程让该节点成为新的主节点：

• 哨兵领导者向上一步选出的从节点发出“slaveof no one”命令，让该节点成为主节点。
• 哨兵领导者向剩余的从节点发送命令，让它们成为新主节点的从节点。
• 哨兵节点集合会将原来的主节点更新为从节点，当其恢复之后命令它去复制新的主节点的数据。