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

Posted 2022-02-14 JavaEdge.

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