Redis 数据倾斜和集群内通信开销

Redis 数据倾斜和集群内通信开销，极客时间《Redis 核心技术与实战》专栏学习笔记 21，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自极客时间《Redis 核心技术与实战》专栏

37 | 数据分布优化：如何应对数据倾斜？

我在阿里云上有一个 Redis 的实例，可惜不支持 Cluster。1

> cluster slots(error) ERR This instance has cluster support disabled

之前的专栏里面没怎么讲过 Hash Tag，我觉的这个倒是一个挺有用的小技巧，从文中的例子来看，可以把一个用户的 profile 和 order 映射到一个 Slot 上。

热点数据多副本，在每一个数据副本的 key 中增加一个随机前缀，这样的话在访问的时候需要客户端做一些工作。

对于课后题，如果热点数据突然过期了，那么应该会造成缓存击穿，会给后台数据库带啦很大的压力。

那么如何避免在数据倾斜的情况下，热点数据过期呢？我觉的可以在每次访问的时候，给缓存数据过期时间增加一个随机的时间段。

看到留言里面说可能会缓存雪崩，我倒是觉得一般不会从击穿到雪崩，不过似乎没有这方面的资料，期待老师的解答。

38 | 通信开销：限制 Redis Cluster 规模的关键因素

今天这个话题应该有点类似屠龙之技，菜鸟如我，什么时候才能有机会运维 100 个以上实例的 Redis Cluster。

Gossip 协议还挺有意思，名字也比较形象。如果翻译成中文，是叫“八卦协议”么？好像容易引起误解。“流言蜚语协议”、“风闻协议”？

一个 ping 消息大概是 104 字节，1000 个实例的 Redis 集群一个 Gossip 消息大概是 12KB，ping-pong 往返，24KB。再加上实例间的通信，那么集群中用于服务正常请求的带宽就会被占用。在这种情况下，是不是采用类似于 Codis 的集中式管理更合适？

将 cluster-node-timeout 从 15 秒调整到 20 或 25 秒，大概能减少 1/3 到 2/3 的实例间通信流量（不知道这个计算是否正确）

PING 消息发送数量 = 1 + 10 * 实例数（最近一次接收 PONG 消息的时间超出 cluster-node-timeout/2）

估计最后还是要靠 tcpdump 来分析实例间的网络带宽变化情况，然后再找出合适的 cluster-node-timeout。但是业务流量经常会有变化，增加了调优的难度。

对于课后题，如果是 Codis 模式，将集群实例状态信息和 Slot 分配信息保存在 Zookeeper 上，那么实例太多之后，查询分配信息的时间也会比较长，另外实时保存实例状态信息也比较难。