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

Posted JavaEdge.

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了亿级流量的动态数据查询解决之道相关的知识,希望对你有一定的参考价值。

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

以上是关于亿级流量的动态数据查询解决之道的主要内容,如果未能解决你的问题,请参考以下文章

小工匠聊架构-布隆过滤器在亿级流量的电商系统中的应用

Redis还是Redis,碰上亿级流量别慌!

亿级推广流量仍能精准推荐?解读核心算法的应用实践

亿级流量高并发秒杀系统商品“超卖”了,只因使用的JDK同步容器中存在这两个巨大的坑!!(踩坑实录,建议收藏)

亿级流量高并发秒杀系统商品“超卖”了,只因使用的JDK同步容器中存在这两个巨大的坑!!(踩坑实录,建议收藏)

京东活动系统--亿级流量架构应对之术