Redis 核心技术与实战
蒋德钧
中科院计算所副研究员
25208 人已学习
立即订阅
登录后,你可以任选4讲全文学习
推荐试读
换一换
02 | 数据结构:快速的Redis有哪些慢操作?
04 | AOF日志:宕机了,Redis如何避免数据丢失?
17 | 为什么CPU结构也会影响Redis的性能?
课程目录
已完结/共 53 讲
开篇词 (1讲)
开篇词 | 这样学Redis,才能技高一筹
基础篇 (10讲)
01 | 基本架构:一个键值数据库包含什么?
02 | 数据结构:快速的Redis有哪些慢操作?
03 | 高性能IO模型:为什么单线程Redis能那么快?
04 | AOF日志:宕机了,Redis如何避免数据丢失?
05 | 内存快照:宕机后,Redis如何实现快速恢复?
06 | 数据同步:主从库如何实现数据一致?
07 | 哨兵机制:主库挂了,如何不间断服务?
08 | 哨兵集群:哨兵挂了,主从库还能切换吗?
09 | 切片集群:数据增多了,是该加内存还是加实例?
10 | 第1~9讲课后思考题答案及常见问题答疑
实践篇 (28讲)
11 | “万金油”的String,为什么不好用了?
12 | 有一亿个keys要统计,应该用哪种集合?
13 | GEO是什么?还可以定义新的数据类型吗?
14 | 如何在Redis中保存时间序列数据?
15 | 消息队列的考验:Redis有哪些解决方案?
16 | 异步机制:如何避免单线程模型的阻塞?
17 | 为什么CPU结构也会影响Redis的性能?
18 | 波动的响应延迟:如何应对变慢的Redis?(上)
19 | 波动的响应延迟:如何应对变慢的Redis?(下)
20 | 删除数据后,为什么内存占用率还是很高?
21 | 缓冲区:一个可能引发“惨案”的地方
22 | 第11~21讲课后思考题答案及常见问题答疑
23 | 旁路缓存:Redis是如何工作的?
24 | 替换策略:缓存满了怎么办?
25 | 缓存异常(上):如何解决缓存和数据库的数据不一致问题?
26 | 缓存异常(下):如何解决缓存雪崩、击穿、穿透难题?
27 | 缓存被污染了,该怎么办?
28 | Pika:如何基于SSD实现大容量Redis?
29 | 无锁的原子操作:Redis如何应对并发访问?
30 | 如何使用Redis实现分布式锁?
31 | 事务机制:Redis能实现ACID属性吗?
32 | Redis主从同步与故障切换,有哪些坑?
33 | 脑裂:一次奇怪的数据丢失
34 | 第23~33讲课后思考题答案及常见问题答疑
35 | Codis VS Redis Cluster:我该选择哪一个集群方案?
36 | Redis支撑秒杀场景的关键技术和实践都有哪些?
37 | 数据分布优化:如何应对数据倾斜?
38 | 通信开销:限制Redis Cluster规模的关键因素
期中测试 (2讲)
期中测试题 | 一套习题,测出你的掌握程度
期中测试题答案 | 这些问题,你都答对了吗?
未来篇 (3讲)
39 | Redis 6.0的新特性:多线程、客户端缓存与安全
40 | Redis的下一步:基于NVM内存的实践
41 | 第35~40讲课后思考题答案及常见问题答疑
加餐篇 (7讲)
加餐(一)| 经典的Redis学习资料有哪些?
加餐(二)| 用户Kaito:我是如何学习Redis的?
加餐(三)| 用户Kaito:我希望成为在压力中成长的人
加餐(四) | Redis客户端如何与服务器端交换命令和数据?
加餐(五) | Redis有哪些好用的运维工具?
加餐(六)| Redis的使用规范小建议
加餐(七) | 从微博的Redis实践中,我们可以学到哪些经验?
结束语 (2讲)
期末测试 | 这些Redis核心知识,你都掌握了吗?
结束语 | 从学习Redis到向Redis学习
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/1000字
划线
笔记
复制
02 | 数据结构:快速的Redis有哪些慢操作?
04 | AOF日志:宕机了,Redis如何避免数据丢失?
17 | 为什么CPU结构也会影响Redis的性能?
24 | 替换策略:缓存满了怎么办?
40 | Redis的下一步:基于NVM内存的实践
41 | 第35~40讲课后思考题答案及常见问题答疑
开通超级会员免费畅看本课程
开通会员
该文章仅可免费阅读部分内容,如需阅读完整文章,请开通超级会员或单独购买本课程。
登录 后留言

精选留言(17)

  • 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 负责提供友好的运维界面,每个组件都可以单独升级,这些组件相互配合,完成整个集群的对外服务。但其缺点是组件比较多,部署和维护比较复杂。

    在实际的业务场景下,我觉得应该尽量避免非常大的分片集群,太大的分片集群一方面存在通信开销大的问题,另一方面也会导致集群变得越来越难以维护。而且当集群出问题时,对业务的影响也比较集中。建议针对不同的业务线、业务模块,单独部署不同的分片集群,这样方便运维和管理的同时,出现问题也只会影响某一个业务模块。
    2020-11-20
    8
    104
  • 张申傲
    看到 Gossip 协议,第一时间想到了《人类简史》中说的:八卦是人类进步的动力,但是集群超过一定规模时,八卦的作用就十分有限了。

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

    2020-12-22
    4
    30
  • xuanyuan
    可以划分管理面和数据面,集群通信走单独的网络

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

    2020-12-09
    7
  • 唐朝首都
    集群的规模应该是可以进一步扩大的。因为集群的信息保存在了第三方存储系统上,意味着redis cluster内部不用再沟通了,这将节省下大量的集群内部的沟通成本。当然就整个集群而言部署、维护也会更加复杂,毕竟引入了一个第三方组件来管理集群。
    2020-11-25
    4
  • 璩雷
    约到后面,评论的人越少,看来坚持到最后的人不多啊~~
    2021-07-30
    2
    2
  • neohope
    用Gossip协议管理配置和Zookeeper统一存储配置信息各有利弊。
    Gossip协议在节点间传递配置让系统简单,而且发生网络故障时自行恢复能力更强一些,但通讯效率随着网络节点的增加而降低;
    Zookeeper统一管理配置,通讯效率无论节点多少都比较高,但让系统架构更复杂故障点增多,对抗网络故障时自行恢复能力差一些。
    但其实无论哪种方式,节点太多了都会更加难以管理维护,出现问题影响面也更难以控制,不推荐。
    但其实另一个极端,就是单个实例性能特别高,存储特别多数据也不推荐,同样也是更容易出问题,出现问题影响面太大,不推荐。
    2021-02-24
    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
    2021-06-13
    1
  • Jasper
    打卡
    2022-01-26
  • Heaven
    好处在于,这样减少了每个实例的负担,保证了元信息的一致性
    坏处是集群系统中需要额外维护第三方系统,增加了系统复杂度
    2021-09-06
  • cake
    我们也不要把 cluster-node-timeout 调得太大,否则,如果实例真的发生了故障,我们就需要等待 cluster-node-timeout 时长后,才能检测出这个故障,这又会导致实际的故障恢复时间被延长,会影响到集群服务的正常使用。 老师请问下这句话 不是因该是 发生故障 cluster-node-timeout /2 就能检测出故障吗? 因为 pong 超过 cluster-node-timeout /2 就会发送ping,为什么是cluster-node-timeout 之后才能检测出故障呢
    2021-08-21
    1
  • Geek_0340e5
    我一直想问个问题,是每个redis实例配置到一台计算机上?还是每个计算机的物理核上绑定一个redis实例?
    2021-06-29
    1
  • escray
    今天这个话题应该有点类似屠龙之技,菜鸟如我,什么时候才能有机会运维 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 上,那么实例太多之后,查询分配信息的时间也会比较长,另外实时保存实例状态信息也比较难。
    2021-04-04
  • 出卖灵魂的教练kerry
    老师你好,有个疑惑,选择一个节点Ping,这个节点是主节点还是主从节点都可以?
    2021-03-31
  • 旅途
    找到了 PONG 消息接收超过 cluster-node-timeout/2的节点之后,是其他所有的实例给它发消息?
    2020-12-15
    1
  • 范闲
    集群的规模可以进一步扩大。
    相当于前面套了一层proxy,proxy从zookeeper获取相关slot信息,然后做请求转发即可?
    2020-12-03
  • 向东是大海
    请教老师一个问题:Redis 哨兵模式中,默认情况下从实例是否接受读请求?哨兵模式中从实例的规模有没有限制?假设单个实例每秒能支撑 8 万 QPS,使用“一主二从三哨兵”方式部署,“一主二从”能支撑 8 万 QPS * 3 = 24 万 QPS 吗?
    2020-11-20
  • “PING 消息中封装了发送消息的实例自身的状态信息、部分其它实例的状态信息,以及 Slot 映射表。” 如果两个实例中包含的“其他实例的状态信息” 不一致,实例2如何处理呢?是比较时间戳吗?
    2020-11-20
    1
收起评论
17
返回
顶部