Redis 核心技术与实战
蒋德钧
中科院计算所副研究员
79224 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 53 讲
开篇词 (1讲)
实践篇 (28讲)
Redis 核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

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

你好,我是蒋德钧。
Redis Cluster 能保存的数据量以及支撑的吞吐量,跟集群的实例规模密切相关。Redis 官方给出了 Redis Cluster 的规模上限,就是一个集群运行 1000 个实例。
那么,你可能会问,为什么要限定集群规模呢?其实,这里的一个关键因素就是,实例间的通信开销会随着实例规模增加而增大在集群超过一定规模时(比如 800 节点),集群吞吐量反而会下降。所以,集群的实际规模会受到限制。
今天这节课,我们就来聊聊,集群实例间的通信开销是如何影响 Redis Cluster 规模的,以及如何降低实例间的通信开销。掌握了今天的内容,你就可以通过合理的配置来扩大 Redis Cluster 的规模,同时保持高吞吐量。

实例通信方法和对集群规模的影响

Redis Cluster 在运行时,每个实例上都会保存 Slot 和实例的对应关系(也就是 Slot 映射表),以及自身的状态信息。
为了让集群中的每个实例都知道其它所有实例的状态信息,实例之间会按照一定的规则进行通信。这个规则就是 Gossip 协议。
Gossip 协议的工作原理可以概括成两点。
一是,每个实例之间会按照一定的频率,从集群中随机挑选一些实例,把 PING 消息发送给挑选出来的实例,用来检测这些实例是否在线,并交换彼此的状态信息。PING 消息中封装了发送消息的实例自身的状态信息、部分其它实例的状态信息,以及 Slot 映射表。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Redis 核心技术与实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(26)

  • 最新
  • 精选
  • 张申傲
    看到 Gossip 协议,第一时间想到了《人类简史》中说的:八卦是人类进步的动力,但是集群超过一定规模时,八卦的作用就十分有限了。

    作者回复: 看到Gossip的八卦本质了 :)

    5
    49
  • xuanyuan
    可以划分管理面和数据面,集群通信走单独的网络

    作者回复: 这是一个方法。分布式系统的通信中,控制平面和数据平面通常会分开来。

    15
  • Kaito
    如果采用类似 Codis 保存 Slot 信息的方法,把集群实例状态信息和 Slot 分配信息保存在第三方的存储系统上(例如Zookeeper),这种方法会对集群规模产生什么影响? 由于 Redis Cluster 每个实例需要保存集群完整的路由信息,所以每增加一个实例,都需要多一次与其他实例的通信开销,如果有 N 个实例,集群就要存储 N 份完整的路由信息。而如果像 Codis 那样,把 Slot 信息存储在第三方存储上,那么无论集群实例有多少,这些信息在第三方存储上只会存储一份,也就是说,集群内的通信开销,不会随着实例的增加而增长。当集群需要用到这些信息时,直接从第三方存储上获取即可。 Redis Cluster 把所有功能都集成在了 Redis 实例上,包括路由表的交换、实例健康检查、故障自动切换等等,这么做的好处是,部署和使用非常简单,只需要部署实例,然后让多个实例组成切片集群即可提供服务。但缺点也很明显,每个实例负责的工作比较重,如果看源码实现,也不太容易理解,而且如果其中一个功能出现 bug,只能升级整个 Redis Server 来解决。 而 Codis 把这些功能拆分成多个组件,每个组件负责的工作都非常纯粹,codis-proxy 负责转发请求,codis-dashboard 负责路由表的分发、数据迁移控制,codis-server 负责数据存储和数据迁移,哨兵负责故障自动切换,codis-fe 负责提供友好的运维界面,每个组件都可以单独升级,这些组件相互配合,完成整个集群的对外服务。但其缺点是组件比较多,部署和维护比较复杂。 在实际的业务场景下,我觉得应该尽量避免非常大的分片集群,太大的分片集群一方面存在通信开销大的问题,另一方面也会导致集群变得越来越难以维护。而且当集群出问题时,对业务的影响也比较集中。建议针对不同的业务线、业务模块,单独部署不同的分片集群,这样方便运维和管理的同时,出现问题也只会影响某一个业务模块。
    8
    150
  • 唐朝首都
    集群的规模应该是可以进一步扩大的。因为集群的信息保存在了第三方存储系统上,意味着redis cluster内部不用再沟通了,这将节省下大量的集群内部的沟通成本。当然就整个集群而言部署、维护也会更加复杂,毕竟引入了一个第三方组件来管理集群。
    6
  • 璩雷
    约到后面,评论的人越少,看来坚持到最后的人不多啊~~
    2
    5
  • Ming
    其实集群不要大,大了通讯是个问题同样后期维护也是个很大的麻烦;不同业务的redis集群区分开来,这样每个集群不至于太大,也不至于一个集群出问题影响到别的业务;
    2
  • neohope
    用Gossip协议管理配置和Zookeeper统一存储配置信息各有利弊。 Gossip协议在节点间传递配置让系统简单,而且发生网络故障时自行恢复能力更强一些,但通讯效率随着网络节点的增加而降低; Zookeeper统一管理配置,通讯效率无论节点多少都比较高,但让系统架构更复杂故障点增多,对抗网络故障时自行恢复能力差一些。 但其实无论哪种方式,节点太多了都会更加难以管理维护,出现问题影响面也更难以控制,不推荐。 但其实另一个极端,就是单个实例性能特别高,存储特别多数据也不推荐,同样也是更容易出问题,出现问题影响面太大,不推荐。
    2
  • 悟空聊架构
    Gossip 协议还有很多有意思的东西,可以参照这篇: 病毒传播:全靠 Gossip 协议: http://www.passjava.cn/#/92.%E5%88%86%E5%B8%83%E5%BC%8F/08.Gossip%E5%8D%8F%E8%AE%AE
    1
  • 小耿
    这种方法会将所有实例之间的两两通信,转换成实例和第三方服务器之间的单一通信,能大幅减少通信次数,从而减少集群运行所占用的网络带宽,实现更大规模的集群。
    归属地:北京
  • 风轻扬
    tcpdump命令,执行之后会报错:syntax error,在host和port之间加一个and就可以了。如下: tcpdump host 192.168.10.3 and port 16379 -i 网卡名 -w /tmp/r1.cap
    归属地:北京
收起评论
显示
设置
留言
26
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部