redis cluster偏偏使用16384個(gè)槽原因是什么

總結(jié)一下，主要兩個(gè)原因：

1. 消息大小的考慮，槽位數(shù)越大，維護(hù)槽位信息占用空間越大，浪費(fèi)帶寬，也容易導(dǎo)致網(wǎng)絡(luò)擁塞。

redis cluster中將節(jié)點(diǎn)加入到集群，需要執(zhí)行cluster meet ip:port來完成節(jié)點(diǎn)的握手操作，之后節(jié)點(diǎn)間就可以通過定期ping-pong來交換信息，其消息頭結(jié)構(gòu)體如下:

#define CLUSTER_SLOTS 16384
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;

其中的unsigned char myslots[CLUSTER_SLOTS/8];維護(hù)了當(dāng)前節(jié)點(diǎn)持有槽信息的bitmap。每一位代表一個(gè)槽，對(duì)應(yīng)位為1表示此槽屬于當(dāng)前節(jié)點(diǎn)。因?yàn)?code>#define CLUSTER_SLOTS 16384故而myslots占用空間為:16384/8/1024=2kb,但如果#define CLUSTER_SLOTS為65536,則占用了8kb。

而且在消息體中也會(huì)攜帶其他節(jié)點(diǎn)的信息用于交換。這個(gè)“其他節(jié)點(diǎn)的信息”具體約為集群節(jié)點(diǎn)數(shù)量的1/10，至少攜帶3個(gè)節(jié)點(diǎn)的信息。故而集群節(jié)點(diǎn)越多，消息內(nèi)容占用空間就越大。

2. redis集群的主節(jié)點(diǎn)數(shù)據(jù)一般不可能超過1000個(gè)。

節(jié)點(diǎn)越多，交換信息報(bào)文也越大；另一方面因?yàn)楣?jié)點(diǎn)槽位信息是通過bitmap維護(hù)的，傳輸過程中會(huì)對(duì)bitmap進(jìn)行壓縮。如果槽位越小，節(jié)點(diǎn)也少的情況下，bitmap的填充率slots/N(N表示節(jié)點(diǎn)數(shù))就較小，對(duì)應(yīng)壓縮率就高。反之節(jié)點(diǎn)很少槽位很多則壓縮率就很低。

所以綜合考慮，作者覺得實(shí)際上16384個(gè)槽位就夠了。