首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >亿级流量的动态数据查询解决之道

亿级流量的动态数据查询解决之道

作者头像
JavaEdge
发布于 2022-01-30 06:05:11
发布于 2022-01-30 06:05:11
5080
举报
文章被收录于专栏:JavaEdgeJavaEdge

DB主从分离、分库分表后,随并发和数据量增长,磁盘I/O成为系统性能瓶颈,于是缓存上场了!

1 什么是缓存

一种存储数据的组件,让对数据请求更快返回。 某些场景下可能还会使用SSD作为冷数据的缓存。比如说360开源的Pika就是使用SSD存储数据解决Redis的容量瓶颈的。

凡是位于速度相差较大的两种硬件之间,用于协调两者数据传输速度差异的结构,均可称为缓存

常见硬件组件延时:

做一次内存寻址大概需要100ns,而一次磁盘查找则需10ms。 使用内存作为缓存的存储介质相比以磁盘作为主要存储介质的DB,性能会提高多个数量级,也能支撑更高并发。所以,内存是最常见的一种缓存数据的介质。

2 适用场景

2.1 Linux内存管理的MMU(Memory Management Unit)

实现从虚拟地址到物理地址的转换,但若每次转换都要做这么复杂计算,无疑会造成性能损耗,所以借助TLB(Translation Lookaside Buffer)缓存最近转换过的【虚拟地址和物理地址的映射】。这就是一种缓存组件,缓存复杂运算的结果。

2.2 短视频

实际上是使用内置的网络播放器来完成的。网络播放器接收的是数据流,将数据下载下来之后经过分离音视频流,解码等流程后输出到外设设备上播放。若在打开一个视频时,才开始下载数据,无疑增加视频打开速度(首播时间),且播放过程中会卡顿。所以播放器中通常会设计一些缓存组件,在未打开视频时缓存一部分视频数据,比如打开x音,服务端可能一次返回三个视频信息,播放第一个视频时,播放器已帮我们缓存第二、三个视频的部分数据,这样在看第二个视频的时候就可以给用户“秒开”体验。

2.3 HTTP协议

第一次请求静态资源时,如一张图片,服务端除返回图片信息,在响应头里还有一个“etag”字段。ETagHTTP响应头是资源的特定版本标识符。可让缓存更高效,并节省带宽,因为若内容没变,Web服务器无需发送完整响应。而若内容发生变化,使用ETag有助于防止资源的同时更新相互覆盖。

若给定URL中的资源更改,则一定要生成新Etag值。 因此Etags类似于指纹,也可能被某些服务器用于跟踪。 比较etags能快速确定此资源是否变化,但也可能被跟踪服务器永久存留。

浏览器会缓存图片信息及该字段值。当下一次再请求该图片时,浏览器发起的请求头里有个“If-None-Match”的字段,并且把缓存的“Etag”的值写进去发给服务端。

3 缓存 V.S 缓冲区

缓存:

  • 可提高低速设备的访问速度
  • 减少复杂耗时的计算带来的性能问题

理论上可通过缓存解决所有“慢”,如从磁盘随机读取数据慢,从DB查询数据慢,只是不同场景消耗的存储成本不同。

而缓冲区是块临时存储数据的区域,这些数据后面会被传输到其他设备。缓冲区更像MQ,用以弥补高速设备和低速设备通信时的速度差。如将数据写入磁盘时并不是直接刷盘,而是写到一块缓冲区,内核会标识该缓冲区为脏。当经过一定时间或脏缓冲区比例到达阈值,由单独线程把脏块刷盘,避免每次写数据都要刷盘的性能消耗。

4 分类

4.1 静态缓存

Web 1.0时盛行,通过生成Velocity模板或静态HTML文件实现静态缓存。

在Nginx上部署静态缓存可减少对后台服务器压力。如做内容管理系统,后台会录入很多文章,前台在网站上展示文章内容,就像新浪,网易这种门户网站。

也可将文章录DB,然后前端展示时,穿透查询DB,但这样会对DB很大压力。即使使用分布式缓存挡读请求,但对于像日均PV几十亿的大型门户网站来说,基于成本考虑仍不划算。

所以解决思路是每篇文章在录入的时候渲染成静态页面,放置在所有前端Nginx或Squid等Web服务器上,这样用户在访问时,优先访问Web服务器上的静态页面,在对旧文章执行一定清理策略后,依然可保证99%以上缓存命中率。

这种缓存只能针对静态数据缓存,动态请求无能为力,就需要分布式缓存了。

4.2 分布式缓存

Redis就是分布式缓存典型,性能强劲,通过分布式方案组成集群可以突破单机的限制。

  • 静态资源缓存选择静态缓存
  • 动态请求可选择分布式缓存

那何时考虑热点本地缓存呢?

遇到极端热点数据查询时,热点本地缓存主要部署在应用服务器代码中,以阻挡热点查询对分布式缓存节点或DB的压力。

如某明星离婚,吃瓜们会到他微博下围观,这就会引发该用户信息的热点查询。这些查询通常会命中某一缓存节点或某一DB分区,短时间内会形成极高热点查询。

4.3 本地缓存

如HashMap,Guava Cache,它们和应用程序部署在同一进程,好处就是无需跨网络调度,速度极快,可阻挡短时间内热点查询。

如垂直电商系统首页的推荐商品,这些商品信息由运营在后台录入和变更。你分析运营录入新的商品或变更某商品信息后,在页面的展示允许有一些延迟,如30s延迟,且首页请求量最大,即使使用分布式缓存也很难抗,所以使用Guava Cache将所有推荐商品的信息缓存起来设置每隔30s重新从DB加载最新的所有商品。

首先,初始化Guava 的Loading Cache:

获取所有商品信息时,可调用Loading Cache的get,优先从本地缓存获取商品信息,若不存在,会使用CacheLoader中逻辑从DB加载所有商品。

由于本地缓存部署在应用服务器,通常集群部署,当数据更新时,不能确定哪台服务器本地中了缓存,更新或删除所有服务器的缓存不是好选择,所以通常会等待缓存过期。因此,这种缓存的有效期很短,通常为min或s级别,以避免返给前端脏数据。

5 缓存的缺陷

缓存不是银弹:

  • 适于读多写少且数据带有一定热点属性 缓存受限存储介质,不可能缓存所有数据,当数据有热点属性时,才能保证缓存命中率。如朋友圈这种20%内容会占80%流量。所以,一旦当业务场景读少写多时或无明显热点,如搜索场景,每个人搜索词都不同,无明显热点,缓存无明显意义。
  • 给整体系统带来复杂度,且有数据不一致问题 当更新DB成功,更新缓存失败场景下,缓存中就会存在脏数据。
  • 缓存通常使用内存作为存储介质,但内存并非无限 因此,使用缓存时要做数据存储量级评估,需消耗极大存储成本的数据,慎用缓存。缓存一定要设置TTL,可保证缓存中的会是热点数据。
  • 缓存会给运维也带来一定的成本 运维需要对缓存组件有一定的了解,排查问题时,也多了考量。

6 总结

缓存可以有多层,如:

  • 静态缓存处在负载均衡
  • 分布式缓存处在应用层和数据库层之间
  • 本地缓存处在应用层

需要将请求尽量挡在上层,因为越往下层,对于并发的承受能力越差。缓存命中率是缓存最重要的监控项。

缓存不仅仅是一种组件的名字,更是一种设计思想,任何能够加速读请求的组件和设计方案都是缓存思想的体现。而这种加速通常是通过两种方式来实现:

  • 使用更快的介质,如内存
  • 缓存复杂运算的结果,如TLB

当你在实际工作中碰到“慢”问题,缓存就是你的第一考量。

参考

  • https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/ETag
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2022/01/29 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
亿级流量网站架构核心技术【笔记】(二)
九、应用级缓存 A.缓存简介 1.先从缓存中读取数据,如果没有,再从慢速设备上读取实际数据并同步到缓存 2.经常读取的数据、频繁访问的数据、热点数据、I/O瓶颈数据、计算昂贵的数据、符合5分钟法则和局部性原理的数据都可以缓存 B.缓存命中率 1.缓存命中率=从缓存中读取次数/【总读取次数(从缓存中读取次数+从慢速设备上读取次数)】 C.缓存回收策略 1.基于空间,指缓存设置了存储空间 2.基于容量,指缓存设置了最大大小 3.基于时间
硬核项目经理
2019/08/06
1.3K0
亿级流量网站架构核心技术【笔记】(二)
《亿级流量网站架构核心技术》概要 《亿级流量网站架构核心技术》目录一览
本书暂定名称为《亿级流量网站架构核心技术——跟开涛学搭建高可用高并发系统》,如有好的书名建议欢迎留言,必当重谢。内容已交由出版社编辑,相信很快就会和大家见面。主要内容结构和目录如下所示:
大道七哥
2019/08/23
1.9K0
《亿级流量网站架构核心技术》概要

            《亿级流量网站架构核心技术》目录一览
亿级流量网站构架核心技术
四层负载均衡:首先DNS解析到LVS/F5,然后LVS/F5转发给Nginx,再由Nginx转发给后端Real Server
BUG弄潮儿
2021/10/08
9690
亿级流量网站构架核心技术
Redis缓存:热点数据查询的数据库减压策略
当热点数据(如电商首页商品、社交平台热门话题)被频繁查询时,数据库每秒可能承受数万次请求。笔者曾参与一个日活百万级的资讯平台项目,在未引入缓存时,MySQL的CPU峰值飙升至90%,响应延迟突破800ms。这种场景下,Redis作为内存数据库的引入,成为缓解数据库压力的关键策略。
Jimaks
2025/07/03
1161
Redis缓存:热点数据查询的数据库减压策略
高并发系统设计之缓存
这篇文章来聊聊缓存。在处理高流量的互联网应用时,缓存起着至关重要的作用,是优化网站性能的第一手段。
BookSea
2023/09/19
3510
高并发系统设计之缓存
亿级流量下通用的高并发架构设计
高并发意味着系统要应对海量请求。从笔者多年的面试经验来看,很多面试者在面对“什么是高并发架构”的问题时,往往会粗略地认为一个系统的设计是否满足高并发架构,就是看这个系统是否可以应对海量请求。再细问具体的细节时,回答往往显得模棱两可,比如每秒多少个请求才是高并发请求、系统的性能表现如何、系统的可用性表现如何,等等。
江南一点雨
2024/05/10
7510
亿级流量下通用的高并发架构设计
秒杀系统瞬时百万并发流量的六种应对之道
作者:冰河 星球:http://m6z.cn/6aeFbs 博客:https://binghe.gitcode.host 文章汇总:https://binghe.gitcode.host/md/all/all.html 源码获取地址:https://t.zsxq.com/0dhvFs5oR 备注:本文节选自 冰河技术 知识星球《Seckill秒杀系统》专栏,文末有福利! 沉淀,成长,突破,帮助他人,成就自我。 本章难度:★★★☆☆ 本章重点:全面阐述建设秒杀系统挑战的应对之道,知己知彼,方案了然于胸,自然
博文视点Broadview
2023/05/19
5190
秒杀系统瞬时百万并发流量的六种应对之道
亿级流量架构之服务降级思路与方法
1 什么是服务降级? 如果看过我前面对服务限流的分析,理解服务降级就很容易了,对于一个景区,平时随便进出,但是一到春节或者十一国庆这种情况客流量激增,那么景区会限制同时进去的人数,这叫
iginkgo18
2021/12/01
7390
流量洪峰下的亿级商品详情页架构解密
伴随着网站业务发展,需求日趋复杂多样并随时变化。传统静态化方案会遇到业务瓶颈,不能满足瞬变的需求。因此,需要一种能高性能实时渲染的动态化模板技术来解决这些问题。本文和大家分享一下最近一年做的京东商品详情页的架构升级的心路历程。
博文视点Broadview
2020/06/11
1.2K0
流量洪峰下的亿级商品详情页架构解密
高并发、高性能 Web 架构
典型 Web App 架构 以下是一个典型的高负载 web 应用示例:上图展示了一个典型的,三层架构的高性能 Web 应用。这种成熟的架构多年以来已被广泛部署于包括 Google、Yahoo、Facebook、Twitter、Wikipedia 在内的诸多大型 Web 应用中。 反向代理服务 位于三层构架中最外层的反向代理服务器负责接受用户的接入请求,在实际应用中,代理服务器通常至少还要完成以下列表中的一部分任务:连接管理:分别维护客户端和应用服务器的连接池,管理并关闭已超时的长连接。 攻击检测和安全隔
Java高级架构
2018/07/20
1.2K0
后台服务架构高性能设计之道
作者:booleanwang,腾讯 PCG 后台开发工程师 “N 高 N 可”,高性能、高并发、高可用、高可靠、可扩展、可维护、可用性等是后台开发耳熟能详的词了,它们中有些词在大部分情况下表达相近意思。本序列文章旨在探讨和总结后台架构设计中常用的技术和方法,并归纳成一套方法论。 前言 本文主要探讨和总结服务架构设计中高性能的技术和方法,如下图的思维导图所示,左边部分主要偏向于编程应用,右边部分偏向于组件应用,文章将按图中的内容展开。 高性能思维导图 1 无锁化 大多数情况下,多线程处理可以提高并发性能,但
腾讯技术工程官方号
2022/04/27
2.3K0
后台服务架构高性能设计之道
如何设计一个秒杀系统?
这篇分享源自之前购买的极客时间课程《如何设计一个秒杀系统》,以及书籍《亿级流量网站架构核心技术》。
BookSea
2024/06/18
3330
如何设计一个秒杀系统?
淘宝双11,亿级流量高并发是怎么抗住的?看完这篇你就明白了!
本文以设计淘宝网的后台架构为例,介绍从一百个并发到千万级并发情况下服务端的架构的演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知。文章最后汇总了一些架构设计的原则。
macrozheng
2019/11/15
2.2K0
「面试」美团肝了我30+问题
如果你问我,看了这些题就完事了?非也,这只是开始,你需要学习的还有很多,知道路子是怎么走才是重要的勒。
我是程序员小贱
2020/10/29
4980
亿级流量场景下,大型缓存架构设计实现【2】
缓存数据生产服务那一层已经搞定了,相当于三层缓存架构中的本地堆缓存+redis分布式缓存都搞定了
小勇DW3
2019/10/14
5490
亿级流量场景下,大型缓存架构设计实现【2】
有赞多级缓存解决方案怎么做的,你知道吗?
TMC,即“透明多级缓存(Transparent Multilevel Cache)”,是有赞 PaaS 团队给公司内应用提供的整体缓存解决方案。
田帅萌
2019/03/04
1.9K0
有赞多级缓存解决方案怎么做的,你知道吗?
从蓝光到4K,腾讯视频高码率下载背后的技术
本文讲述架构平台部 TVideo平台从资源,链路、缓存、接入进行调优,有效解决4k高码率视频的二次缓冲问题。
腾讯技术工程官方号
2018/01/17
7.1K0
从蓝光到4K,腾讯视频高码率下载背后的技术
淘宝的商品信息缓存体系是如何构建的?
在电商系统中,商品信息的快速获取对用户体验至关重要。本文将详细讲解一个多层级的商品信息缓存体系,旨在提高系统性能和可靠性。
JavaEdge
2025/06/01
770
淘宝的商品信息缓存体系是如何构建的?
优化网站性能必备的6种架构方案,你知道吗?
一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随着业务的扩展而逐步完善的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,例如:淘宝,要解决海量的商品信息的搜索、下单、支付,例如腾讯,要解决数亿用户的实时消息传输,百度它要处理海量的搜索请求,他们都有各自的业务特性,系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下,找出其中共用优化的技术,这些优化技术和手段广泛运用在大型网站系统的架构中,下面让我们来认识这些优化性能的技术和手段。
lyb-geek
2018/11/05
6360
推荐阅读
相关推荐
亿级流量网站架构核心技术【笔记】(二)
更多 >
交个朋友
加入腾讯云官网粉丝站
蹲全网底价单品 享第一手活动信息
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档