引言
Redis集群模式节点之间通过Gossip协议彼此之间传递节点状态、槽等信息，没有依赖元数据组件来维护。简化了架构的同时，通信成本也限制了集群规模。
本文除了走查了通信开销影响因素，还梳理了节点扩缩容和请求路由的原理。主要内容有：
一、通信开销影响因素
二、扩缩容与槽位迁移
三、请求路由与重定向
一、通信开销影响因素

节点数量

每秒从本地实例列表选择5个节点，在这5个节点中选择最久没有通信的实例，向该实例发送PING消息。
即：定时发送PING消息的节点数量=5。
避免一些实例节点一直选不到，会有一个定时任务扫描兜底措施。
集群内部每秒10次的固定频率扫描本地缓存节点列表，也就是每100ms一次。
如果节点：PONG更新时间node.pong_received>（cluster-node-timeout/2）立即向该节点发送PING消息，假设该数量为N。
即：兜底发送的节点数量=10 * N。
通过调大cluster_node_timeout可以减少通信的节点数量，例如：从15秒调整到30秒。
但是，cluster_node_timeout过大会影响故障发现的时间和新节点发现的时间。

消息大小

一次通信包含消息头和消息体。
消息头：PING消息头相对固定，主要占用的发送节点负责的槽位（myslots[CLUSTER_SLOTS/8]）占用2KB。
消息体：会携带一定数量的其他节点信息，默认包含集群总节点数的1/10，最少包含集群的3个节点，最多包含集群总节点数-2。
消息体clusterMsgDataGossip各个字段字节大小，共计104个字节。
属性大小
char nodename[CLUSTER_NAMELEN]40字节
uint32_t ping_sent4字节
uint32_t pong_received4字节
char ip[NET_IP_STR_LEN]46字节
uint16_t port2字节
uint16_t cport2字节
uint16_t flags2字节
uint16_t pport保留字段
uint16_t notused14字节
合计104字节
200个节点的redis集群，一次通信成本：2KB的消息头+2KB的消息体（20*104）= 4KB，一来一回8KB。
携带消息体的大小与集群规模相关，规模越大消息体越大，通信成本越高。
达到一定程度后整体集群性能会下降，Redis Cluster官方建议最大规模1000个实例，实际中通常不会超过500个实例。
二、扩缩容与槽位迁移

节点扩缩容本质上是槽在节点之间的迁移。
节点扩容后，需要将原有节点上的槽迁移到新节点。
如下图所示，当集群中加入节点4时，将节点1的Slo01，节点2的Slot04，节点3的Slot07迁移给节点4以实现数据均衡。
节点缩容前，需要将待下线节点上的槽先迁移走。
如下图所示，当集群中节点4下线，需要先将其拥有的槽位Slot01、Slot04、Slot07迁移走。
槽位迁移命令有：ADDSLOTS、DELSLOTS、FLUSHSLOTS、SETSLOT。

三、请求路由与重定向
数据存储在槽里，槽分布在实例上，处理客户端请求也是找对应槽的过程。

请求重定向

请求路由过程如下：
  • @1 客户端发送请求命令到集群任意节点
  • @2 计算key对应的槽，计算公式：slot=CRC16（key）&16383
  • @3 槽在本节点，执行命令，每个实例维护自身负责的槽也维护其他实例负责的槽位
  • @4 槽不在本节点，回复MOVE到其他节信息点
  • @5 向目标节点发起请求
为了减少MOVE重定向的开销，例如Jedis在客户端实现时缓存了槽与节点的关系，减少通信的开销。
然而也增加了客户端的复杂性，客户端会为集群中每个节点独立的连接池，集群规模大时占用更多的本地缓存。

ASK重定向

如果访问的槽正在做迁移，一部分数据在源节点，而另一部分已经迁移到目标节点，这个流程是如何的？
ASK重定向流程：
  • @1 发送请求命令
  • @2 计算key对应的槽
  • @3 槽在本节点，数据也在，执行命令
  • @4 访问的数据正在迁移，回复ASK信息含请求数据的目标节点
  • @5 向目标节点发起ASKING请求、执行命令获取数据
ASK的重定向是临时性的，客户端（Jedis）收到回复不更新客户端槽与节点映射，而MOVE的重定向会更新本地槽映射关系。
继续阅读
阅读原文