redis之通信开销限制redis cluster规模的关键因素
Posted xzwcomeon
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了redis之通信开销限制redis cluster规模的关键因素相关的知识,希望对你有一定的参考价值。
redis cluster在运行时,每个redis实例上都会保存slot和实例的对应关系,为了让集群中的每个实例都知道其他所有实例的状态信息,实例之间会按照
一定的规则进行通信,这个规则就是gossip协议。
Gossip 协议的工作原理:
一是,每个实例之间会按照一定的频率,从集群中随机挑选一些实例,把 PING 消息发送给挑选出来的实例,用来检测这些实例是否在线,并交换彼此的状态信息。PING 消息中封装了发送消息的实例自身的状态信息、部分其它实例的状态信息,以及 Slot 映射表。
二是,一个实例在接收到 PING 消息后,会给发送 PING 消息的实例,发送一个 PONG 消息。PONG 消息包含的内容和 PING 消息一样。
gossip协议可以保证经过一段时间,所有实例都能获取到其他实例的状态信息。
实例间使用 Gossip 协议进行通信时,通信开销受到通信消息大小和通信频率这两方面的影响。
Gossip消息:
typedef struct {
char nodename[CLUSTER_NAMELEN]; //40字节
uint32_t ping_sent; //4字节
uint32_t pong_received; //4字节
char ip[NET_IP_STR_LEN]; //46字节
uint16_t port; //2字节 uint16_t cport; //2字节
uint16_t flags; //2字节 uint32_t notused1; //4字节}
clusterMsgDataGossip;
每个实例在发送一个 Gossip 消息时,除了会传递自身的状态信息,默认还会传递集群十分之一实例的状态信息。
为了让 Slot 映射表能够在不同实例间传播,PING 消息中还带有一个长度为 16,384 bit 的 Bitmap,这个 Bitmap 的每一位对应了一个 Slot,如果某一位为 1,就表示这个 Slot 属于当前实例。
实例间通信机制:
Redis Cluster 的实例启动后,默认会每秒从本地的实例列表中随机选出 5 个实例,再从这 5 个实例中找出一个最久没有通信的实例,把 PING 消息发送给该实例。这是实例周期性发送 PING 消息的基本做法。这种做法缺点是实例选出来的这个最久没有通信的实例,毕竟是从随机选出的 5 个实例中挑选的,这并不能保证这个实例就一定是整个集群中最久没有通信的实例。这有可能会出现,有些实例一直没有被发送 PING 消息,导致它们维护的集群状态已经过期了。未避免这种情况,redis cluster的实例会按照100ms 一次的频率,扫描本地实例列表,如果发现有实例最近一次接收 PONG 消息的时间,已经大于配置项 cluster-node-timeout 的一半了(cluster-node-timeout/2),就会立刻给该实例发送 PING 消息,更新这个实例上的集群状态信息。
总结:单实例每秒发送的ping消息的数量 1+10(1000ms/10)*实例数(最近一次接收 PONG 消息的时间超出 cluster-node-timeout/2)
如何降低实例间的通信开销:
减小实例传输的消息大小(PING/PONG 消息、Slot 分配信息),但是,因为集群实例依赖 PING、PONG 消息和 Slot 分配信息,来维持集群状态的统一,一旦减小了传递的消息大小,就会导致实例间的通信信息减少,不利于集群维护,所以,不能采用这种方式。
每个实例每 1 秒发送一条 PING 消息。这个频率不算高,如果再降低该频率的话,集群中各实例的状态可能就没办法及时传播了。
每个实例每 100 毫秒会做一次检测,给 PONG 消息接收超过 cluster-node-timeout/2 的节点发送 PING 消息。实例按照每 100 毫秒进行检测的频率,是 Redis 实例默认的周期性检查任务的统一频率,我们一般不需要修改它。配置项 cluster-node-timeout 定义了集群实例被判断为故障的心跳超时时间,默认是 15 秒。如果 cluster-node-timeout 值比较小,那么,在大规模集群中,就会比较频繁地出现 PONG 消息接收超时的情况,从而导致实例每秒要执行 10 次“给 PONG 消息超时的实例发送 PING 消息”这个操作的数量增加。所以,为了避免过多的心跳消息挤占集群带宽,我们可以调大 cluster-node-timeout 值,比如说调大到 20 秒或 25 秒。这样一来, PONG 消息接收超时的情况就会有所缓解,单实例也不用频繁地每秒执行 10 次心跳发送操作了。
以上是关于redis之通信开销限制redis cluster规模的关键因素的主要内容,如果未能解决你的问题,请参考以下文章
Redis学习笔记38——通信开销:限制Redis Cluster规模的关键因素
Redis学习笔记38——通信开销:限制Redis Cluster规模的关键因素