redis cluster保存的数据量及吞吐量跟集群的规模相关,Redis 官方给出了 Redis Cluster
的规模上限,是一个集群运行1000 个实例。为什么规定集群规模上限呢?
集群规模越大越好?
随着集群数量的越来越多,各实例间的通信开销也随之越来越大,到达一定数量,
集群的吞吐量反而下降,所以集群的规模并不是越大越好。redis每个实例上都会
保存slot和实例的映射关系slot映射表,以及自身的状态信息用来跟别的实例通信
告知自身状态。
Gossip 协议
每个实例之间会按照一定的频率,从集群中随机挑选一些实例,把PING消息发送
给挑选出来的实例,用来检测这些实例是否在线,并交换彼此的状态信息。PING 消息中封
装了发送消息的实例自身的状态信息、部分其它实例的状态信息,以及 Slot 映射表。
一个实例在接收到 PING 消息后,会给发送 PING 消息的实例,发送一个 PONG 消
息,PONG 消息包含的内容和 PING 消息一样,gossip协议可以保证集群在经过一段时间
后,各实例都互相拥有其信息,当集群有实例加入退出或者slot变更时,各实例也可以通过
ping pong消息互相通知,完成消息同步
Gossip消息大小
Redis 实例发送的 PING 消息的消息体是由 clusterMsgDataGossip 结构体组成的
每个实例在发送一个 Gossip 消息时,除了会传递自身的状态信息,默认还会传递集群十分
之一实例的状态信息,对于一个包含了 1000 个实例的集群来说,每个实例发送一个
PING 消息时,会包含 100 个实例的状态信息,总的数据量是 10400 字节,再加上发送
实例自身的信息,一个 Gossip 消息大约是 10KB,再加上一个存储slot表的bitmap2kB,
所以一个ping消息大约是12kb,加上pong消息,共24Kb,相较于我们平常处理的业务,
24kb算是很大了,随着集群规模的增大,心跳信息的的增多,会占据集群的部分带宽,
进而影响到集群的吞吐量
实例间通信频率
redis cluster 会默认每秒从本地的实例列表随机挑选5个,然后从其中选出一个最久
没有通信的实例,进而发送ping消息,还会按照100ms一次的频率扫描本地实例列表,
一旦发现实例最近一次接收pong消息的时间大于配置项cluster-node-timeout的一半,
便会立即对其发送ping消息,如果网络堵塞的情况下,就会导致超时的实例变多,进而
使消息交互变多。
PING消息发送数量 = 1 + 10 * 实例数,1是指单实例常规按照每 1 秒发送一个 PING消息
10 是指每 1 秒内实例会执行10 次检查,每次检查后会给 PONG 消息超时的实例发送消息,
假如一秒内的10次检查共发现10台实例pong消息超时,那么每秒得发送101次ping消息,
每个12k,共约占1.2mb/s的带宽,这还是只是单实例,10台便是12mb/s的带宽占用
如何降低通信开销
配置项 cluster-node-timeout 定义了集群实例被判断为故障的心跳超时时间,默认
是 15秒。如果cluster-node-timeout 值比较小,那么,在大规模集群中,就会比较频繁地出
现PONG 消息接收超时的情况,如果值比较大,便会导致实例故障被发现的时间延长,进而
导致实例恢复的时间变长,影响到集群的吞吐量。具体根据系统场景和集群的大小设置
cluster-node-timeout 的大小