Redis源码解读(二十二)——集群模式—gossip协议

Redis的集群模式是去中心化架构,采用gossip协议实现集群中节点间信息同步。
gossip过程是由种子节点发起,当一个种子节点有状态需要更新到网络中的其他节点时,它会随机的选择周围几个节点散播消息,收到消息的节点也会重复该过程,直至最终网络中所有的节点都收到了消息。这个过程可能需要一定的时间,由于不能保证某个时刻所有的节点都收到消息,但是能够保证最终所有节点都会收到消息,因此它是一个最终一致性协议。
本节介绍下Redis中如何通过gossip协议达到节点间信息的最终一致性

消息

Redis集群中通过消息来传递各个节点间的信息,消息由消息头+消息体组成:

typedef struct {
    char sig[4];        /* Signature "RCmb" (Redis Cluster message bus). */
    uint32_t totlen;    /* Total length of this message */
    uint16_t ver;       /* Protocol version, currently set to 1. */
    uint16_t port;      /* TCP base port number. */
    uint16_t type;      /* Message type */
    uint16_t count;     /* Only used for some kind of messages. */
    uint64_t currentEpoch;  /* The epoch accordingly to the sending node. */
    uint64_t configEpoch;   /* The config epoch if it's a master, or the last
                               epoch advertised by its master if it is a
                               slave. */
    uint64_t offset;    /* Master replication offset if node is a master or
                           processed replication offset if node is a slave. */
    char sender[CLUSTER_NAMELEN]; /* Name of the sender node */
    unsigned char myslots[CLUSTER_SLOTS/8];
    char slaveof[CLUSTER_NAMELEN];
    char myip[NET_IP_STR_LEN];    /* Sender IP, if not all zeroed. */
    char notused1[34];  /* 34 bytes reserved for future usage. */
    uint16_t cport;      /* Sender TCP cluster bus port */
    uint16_t flags;      /* Sender node flags */
    unsigned char state; /* Cluster state from the POV of the sender */
    unsigned char mflags[3]; /* Message flags: CLUSTERMSG_FLAG[012]_... */
    union clusterMsgData data;
} clusterMsg;

消息头部分包含了port、epoch、分配的slot、master等信息,消息体为clusterMsgData,根据不同的消息类型,有不同的结构:

union clusterMsgData {
    /* PING, MEET and PONG */
    struct {
        /* Array of N clusterMsgDataGossip structures */
        clusterMsgDataGossip gossip[1];
    } ping;

    /* FAIL */
    struct {
        clusterMsgDataFail about;
    } fail;

    /* PUBLISH */
    struct {
        clusterMsgDataPublish msg;
    } publish;

    /* UPDATE */
    struct {
        clusterMsgDataUpdate nodecfg;
    } update;

    /* MODULE */
    struct {
        clusterMsgModule msg;
    } module;
};

gossip协议使用PING、PONG类型的消息:

typedef struct {
    char nodename[CLUSTER_NAMELEN];
    uint32_t ping_sent;
    uint32_t pong_received;
    char ip[NET_IP_STR_LEN];  /* IP address last time it was seen */
    uint16_t port;              /* base port last time it was seen */
    uint16_t cport;             /* cluster port last time it was seen */
    uint16_t flags;             /* node->flags copy */
    uint32_t notused1;
} clusterMsgDataGossip;

包含了以自身视角看,对应节点的发送PING消息时间、接受PONG消息时间、port已经对应的状态

gossip过程

集群中每个节点在一定时间内向其他节点发送PING消息,收到PING消息的节点回复PONG消息,每个节点通过PING/PONG消息感知其他节点状态,进行状态更新,最终使得集群中每个节点状态达到一致。
何时发送PIONG消息,PING消息都包含哪些节点信息呢,这部分在ClusterCron这个集群模式下的周期性函数实现:
1、随机选择5个节点,如果该节点还没有发送PING消息,选择最迟收到PONG消息的节点,向该节点发送PING消息

/* This is executed 10 times every second */
void clusterCron(void) {
	...
    if (!(iteration % 10)) {
        int j;

        /* Check a few random nodes and ping the one with the oldest
         * pong_received time. */
        // 随机选择5个节点
        for (j = 0; j < 5; j++) {
            de = dictGetRandomKey(server.cluster->nodes);
            clusterNode *this = dictGetVal(de);

            /* Don't ping nodes disconnected or with a ping currently active. */
            // 该节点还没有发送PING消息
            if (this->link == NULL || this->ping_sent != 0) continue;
            // 排除自己和CLUSTER_NODE_HANDSHAKE的节点
            if (this->flags & (CLUSTER_NODE_MYSELF|CLUSTER_NODE_HANDSHAKE))
                continue;
            // 选择最迟收到PONG消息的节点
            if (min_pong_node == NULL || min_pong > this->pong_received) {
                min_pong_node = this;
                min_pong = this->pong_received;
            }
        }
        // 发送PING消息
        if (min_pong_node) {
            serverLog(LL_DEBUG,"Pinging node %.40s", min_pong_node->name);
            clusterSendPing(min_pong_node->link, CLUSTERMSG_TYPE_PING);
        }
    }
    ...
}

2、遍历所有节点,如果有节点长时间内没有发送过PING消息,则发送:

/* This is executed 10 times every second */
void clusterCron(void) {
	...
    di = dictGetSafeIterator(server.cluster->nodes);
    while((de = dictNext(di)) != NULL) {
          /* If we have currently no active ping in this instance, and the
         * received PONG is older than half the cluster timeout, send
         * a new ping now, to ensure all the nodes are pinged without
         * a too big delay. */
        if (node->link &&
            node->ping_sent == 0 &&
            (now - node->pong_received) > server.cluster_node_timeout/2)
        {
            clusterSendPing(node->link, CLUSTERMSG_TYPE_PING);
            continue;
        }
    }
    ...
}

这里面设置的时间阈值为server.cluster_node_timeout/2,在集群模式下,如果节点A向节点B发送PING消息后,超过server.cluster_node_timeout时间内,节点A没有收到节点B的PONG消息,那么节点A就会把节点B设置为PFAIL状态,所以这里判断发送PING消息的时间为server.cluster_node_timeout/2,还要考虑一个回复PONG消息的网络来回时间。

当节点A决定向节点B发送PING消息时,节点A需要构造gossip消息体,会选择集群中的一部分节点,将这部分节点的信息一并发送给节点B,节点B根据这些信息,看情况更新自身的集群信息。
那么节点A需要选取多少个节点,以及选取哪些节点呢,这就需要考虑到消息传播的时效性以及集群规模的折中了。选取的节点过少,集群中各个节点的状态达到最终一致性的时间就边长,选取的节点过多,网络传输量就多大,同时集群中传播的冗余信息就变多,节点对于消息的处理的代价就变大,注意到Redis是单线程模型,集群模式下对于消息的处理是与用户命令处理是同一个线程,过大的消息体的处理必然会占用更多的CPU,这将严重限制集群的规模。按照当前的Redis gossip协议策略,一般可以支持400个左右的节点集群,节点数在增加,就会对用户的命令处理带来较明显的影响。
gossip消息体节点的选取策略在clusterSendPing中实现:

void clusterSendPing(clusterLink *link, int type) {
	...
	int freshnodes = dictSize(server.cluster->nodes)-2;
	wanted = floor(dictSize(server.cluster->nodes)/10);
    if (wanted < 3) wanted = 3;
    if (wanted > freshnodes) wanted = freshnodes;
    ...
    int pfail_wanted = server.cluster->stats_pfail_nodes;
    totlen = sizeof(clusterMsg)-sizeof(union clusterMsgData);
    totlen += (sizeof(clusterMsgDataGossip)*(wanted+pfail_wanted));
}

包含两部分:1/10的总节点数、PFAIL状态的节点数。PFAIL状态的节点需要尽快通知其他节点,以便进行slave的failover。那么集群正常状态下为什么要选取1/10的节点数呢,作者在clusterSendPing中的注释解释了这个问题:按照上面介绍的gossip协议发送时间,每隔server.cluster_node_timeout/2的时间内会向对端节点发送一个PING消息,对端节点会回复一个PONG消息,那么在server.cluster_node_timeout时间内,会处理4个gossip协议,由于PFAIL标志的有效时间是server.cluster_node_timeout2,在这段时间内,共会处理8个gossip协议,假设此时集群中有个节点A宕机,这个宕机节点被另外节点B检测到,节点B将其标志位PFAIL状态,在server.cluster_node_timeout2时间内,节点B可以将发送8次gossip协议,每次带有1/10的节点,那么就有80%的概率将节点A的宕机信息传播给集群中其他节点,同时将PFAIL状态标志位FAIL状态只需要过半的节点数即可,从概率上将,80%的概率足够集群中其他节点标志位PFAIL状态,从而不影响正常的failover。

选取好节点数之和,就是构造并发送gossip协议了,这部分代码较繁琐,直接看代码即可。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值