總結一下，主要兩個原因：

1. 消息大小的考慮，槽位數越大，維護槽位信息占用空間越大，浪費帶寬，也容易導致網絡擁塞。

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

#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];維護了當前節點持有槽信息的bitmap。每一位代表一個槽，對應位為1表示此槽屬于當前節點。因為#define CLUSTER_SLOTS 16384故而myslots占用空間為:16384/8/1024=2kb,但如果#define CLUSTER_SLOTS為65536,則占用了8kb。

而且在消息體中也會攜帶其他節點的信息用于交換。這個“其他節點的信息”具體約為集群節點數量的1/10，至少攜帶3個節點的信息。故而集群節點越多，消息內容占用空間就越大。

2. redis集群的主節點數據一般不可能超過1000個。

節點越多，交換信息報文也越大；另一方面因為節點槽位信息是通過bitmap維護的，傳輸過程中會對bitmap進行壓縮。如果槽位越小，節點也少的情況下，bitmap的填充率slots/N(N表示節點數)就較小，對應壓縮率就高。反之節點很少槽位很多則壓縮率就很低。

所以綜合考慮，作者覺得實際上16384個槽位就夠了。