即时消息技术剖析与实战
袁武林
微博研发中心技术专家
24187 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 25 讲
即时消息技术剖析与实战
15
15
1.0x
00:00/00:00
登录|注册

17 | Cache:多级缓存架构在消息系统中的应用

通过“短过期时间”平衡缓存命中率和数据一致性
低成本解决带宽问题
避免单一节点宕机后穿透到存储层的问题
解决单一热点的带宽问题
单点穿透问题
带宽问题
虚拟节点解决数据倾斜问题
解决节点变化带来的问题
节点变化后可能导致缓存命中率下降
简单实现
如何保持主从缓存的数据热度在有L1缓存层的情况下
本地缓存+L1+主从的多层模式
L1+主从模式
主从模式
一致性哈希
取模求余
需要在“缓存命中率”和“缓存使用量”间平衡
高成本
对系统性能提升的明显作用
高并发应用中的重要性
思考题
缓存热点问题
缓存的分布式算法
缓存的资源成本
缓存
缓存架构在消息系统中的应用

该思维导图由 AI 生成,仅供参考

你好,我是袁武林。
今天,我要带你了解的是一项在 IM 系统中相对比较通用的、使用比较高频的,而且对系统性能提升非常明显的技术:缓存。
说到缓存,你应该不陌生。相对于磁盘操作,基于内存的缓存对耗时敏感的高并发应用来说,在性能方面的提升是非常明显的。
下面是谷歌的技术奠基人杰夫·狄恩(Jeff Dean)给出的一些计算机相关的硬件指标,虽然有些数据可能由于时间太久不够准确,但大致的量级基本还是一致的。
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns
Mutex lock/unlock 100 ns
Main memory reference 100 ns
Compress 1K bytes with Zippy 10,000 ns
Send 2K bytes over 1 Gbps network 20,000 ns
Read 1 MB sequentially from memory 250,000 ns
Round trip within same datacenter 500,000 ns
Disk seek 10,000,000 ns
Read 1 MB sequentially from network 10,000,000 ns
Read 1 MB sequentially from disk 30,000,000 ns
Send packet CA->Netherlands->CA 150,000,000 ns
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

多级缓存架构在消息系统中的应用是一项在IM系统中常见且性能显著的技术。文章介绍了缓存的重要性以及在IM系统中常见的问题和解决方案。首先,讨论了缓存的资源成本高和使用中需要平衡的问题。然后,详细介绍了缓存的分布式算法,包括取模求余和一致性哈希,并重点阐述了一致性哈希算法的优势和解决数据倾斜的方法。接着,针对缓存热点问题,提出了多级缓存架构中的主从模式,并探讨了主从模式在处理突发流量场景下可能存在的问题。整体而言,文章通过实际案例和技术原理,深入浅出地介绍了多级缓存架构在消息系统中的应用,为读者提供了全面的技术视角和解决方案。 在多级缓存架构中,作者提出了L1+主从模式和本地缓存+L1+主从的多层模式两种解决方案。L1+主从模式通过增加L1缓存层,解决了单一热点的带宽问题,也避免了单一节点宕机后容易穿透到DB存储层的情况。而本地缓存+L1+主从的多层模式则在L1+主从模式的基础上,引入了本地缓存,充分利用应用服务器的带宽和少量内存,低成本地解决带宽问题。同时,文章还提到了解决本地缓存一致性问题的方法,即采用“短过期时间”的方式来平衡缓存命中率和数据更新一致性的问题。 总的来说,本文通过介绍缓存的重要性、分布式算法和多级缓存架构的应用,为读者提供了全面的技术视角和解决方案。同时,文章还提出了一个思考题,引发读者对于多级缓存架构的进一步思考和讨论。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《即时消息技术剖析与实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(29)

  • 最新
  • 精选
  • 那时刻
    请问怎么保证local cache到cache master的数据一致性呢?毕竟local cache在分布式的服务器集群,会有同一个文档发到不同服务器local cache的情形。从图中看出,是某一个local cache负责同步数据到cache master么?或者我有什么误解?烦请指正

    作者回复: 本地缓存的一致性我课程中有讲哈,本地缓存只会从中央缓存回种,中央缓存数据有变化并不需要同步告知本地缓存。本地缓存通过短过期时间来重新从中央缓存回种。

    2019-10-06
    2
    10
  • 小小小丶盘子
    开线程定时访问热点数据,保证不被淘汰。

    作者回复: 也是一种思路,不过实现上可能会比较复杂。另外可以考虑把master也加入到L1缓存层中,这样能保持数据热度。

    2019-10-04
    8
  • 好运连连
    为什么把master也当作L1可以解决热度问题?难道每一次master过期也会主动把从库的对应缓存删除?

    作者回复: master加入到L1层主要是解决master的热点数据缓存得不到访问而被lru淘汰掉,如果这时L1挂了或者被下线,会穿透master对底层db产生压力。对于redis这种本身支持主从的缓存实现,master上过期了slave上也会过期,对于memcached这种本身不支持主从的缓存实现就需要人为来维护主从关系,数据也并不会从master同步到slave。

    2019-11-12
    2
    5
  • Geek_37e993
    请教一下,L1缓存和slave以及后端存储的数据一致性如何保证呢?

    作者回复: 有数据更新的时候会同步更新L1和master,虽然多组L1会导致多次更新的问题,但对于大部分读多写少的互联网场景来说刚更新不是一个频繁的操作,所以基本可控。

    2019-10-09
    2
    4
  • clip
    主从以及那边有点不明白。 为什么从库节点中有全部的数据? 某个节点有全量的数据却只有部分对象的查询分配到自己。 我理解的如果有全量数据那就直接循环着去不同节点中取不就行了吗,也就不需要缓存分布式算法了吧。

    作者回复: 不是哈,这里是说:对于主从缓存来说,从库拥有和主库一样的数据,所以靠不停扩展多个从库来解决某几个单key热点的问题很浪费。并不是说每个主从都有全量所有的业务数据,主从里的数据是根据hash规则来分片的,是全量数据的子集。

    2019-10-08
    4
  • 大魔王汪汪
    老师L1缓存具体是实现和缓存层究竟有什么区别呢?还是说技术实现上本身没有区别,只不过存储目的不同?比如L1就是为了解决热数据的

    作者回复: 技术实现上基本一样,只不过L1主要解决热数据对master slave缓存的单点压力,也可以防止master slave缓存故障导致穿透db的问题。

    2019-10-07
    3
  • AI
    对于L1解决带宽问题,感觉文中没讲太清楚。机器带宽和网卡有关系,相同配置的机器带宽一样。从库和L1如果机器数量一样,同样带宽是没问题的。也就是说L1在存储成本上有优势,带宽上没优势吧?

    作者回复: L1的容量一般比从库容量小很多,但是会冗余多组,通过这种方式来承担极热点数据的访问,带宽上由于冗余多组来随机访问,所以带宽上自然相当于扩大了,另外由于容量都很小,也比扩从库成本上要更省。

    2019-10-15
    2
  • yic
    老师,有两个问题请教一下: 1. L1缓存业界一般是如何实现的? 2. 关于课后问题的解答,老师提供的思路是:“另外可以考虑把master也加入到L1缓存层中,这样能保持数据热度“。我想问一下,如果发生了主从关系变化呢?这时如何把master加入到L1缓存层呢?

    作者回复: L1缓存一般也是和主从缓存一样,采用中央缓存如memcached或者redis,只是在hash规则上和主从缓存有区别。 您指的主从关系变化是说节点数变化了还是主库切成从库了?如果是节点数发生了变化采用一致性hash是可以不需要干预的,如果是主从关系变化了一般需要及时调整L1的配置。

    2019-11-07
    2
    1
  • 独酌相思解千愁
    对于思考题,将各级缓存的存活时间分级设定,L1最小,每当L1重新拉取数据时同时更新其他缓存层的相应热点数据。同时对于一段时间类使用比较频繁的数据可以按照一定规则增加其存活时间(或者权重) 不知道这样有可行性不

    作者回复: 理论上应该可以,不过L1如果承载的是热点数据,那么对于更新主从缓存就会比较频繁,带来额外压力。一种简单的方法可以把主从缓存也作为一组L1加入,这样也能保证主从缓存里的数据热度。

    2019-11-06
    1
  • 王蒙
    举个例子,单台机器 120MB 带宽,对于 1MB 大小的文章来说,如果 QPS 到 1000 的话,至少需要 8 个实例才可以抗住。 请问,8是怎么算的,有什么公式吗? 8个实例是指单台物理机,上面8个虚拟机,还是一台机器上部8个相同应用? 还有平时手机的流量是指http请求的request的请求头和body的大小吗,response的算吗?

    作者回复: QPS 1000的话整体流量就是1G,一般常见的千兆网卡单台机器单方向120MB带宽, 所以大概需要8台左右。 这里的流量是指网卡流量,http属于应用层的,所以是包括header和body的。

    2019-11-05
    1
收起评论
显示
设置
留言
29
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部