MySQL数据库成为瓶颈后，动态数据的查询要如何加速？

保举学习

• 牛掰！“基础-中级-高级”Java程序员面试集结，看完献出我的膝盖
  
• 全网首发！马士兵内部共享—1658页《Java面试突击核心讲》
  

                               
登录/注册后可看大图

一般电商体系在完成DB主从分离和分库分表后，可支持十几万DAU。
DB分了主库和、从库，数据也被切分到多个DB节点。但随并发增加，存储数据量增多，DB磁盘IO逐渐成体系瓶颈，需要一种访问更快的组件来降低哀求响应时间，提拔团体体系性能。
这时，就该缓存上场了！
什么是缓存

缓存，一种存储数据的组件，让对数据的哀求更快返回。
经常会把缓存放在内存， 所以有人就以为内存=缓存，这是生手看法。
某些场景下可能还会使用SSD作为冷数据的缓存。好比说360开源的Pika就是使用SSD存储数据解决Redis的容量瓶颈的。
凡是位于速度相差较大的两种硬件之间，用于协调两者数据传输速度差异的结构，均可称之为缓存。
常见硬件组件的延时情况是什么样的了，如许在做方案的时候可以对耽误有更直观的印象。

                               
登录/注册后可看大图

做一次内存寻址大概需要100ns，而做一次磁盘的查找则需要10ms。
使用内存作为缓存的存储介质相比于以磁盘作为重要存储介质的数据库来说，性能上会提高多个数量级，同时也可以或许支持更高的并发量。所以，内存是最常见的一种缓存数据的介质。
缓存作为一种常见的空间换时间的性能优化手段，在很多地方都有应用。
缓存的适用场景

Linux内存管理通过MMU（Memory Management Unit）硬件，实现从虚拟地址到物理地址的转换，但如果每次转换都要做这么复杂计算，无疑会造成性能损耗，所以借助TLB（Translation Lookaside Buffer）组件缓存近来转换过的虚拟地址，和物理地址的映射。这就是一种缓存组件，缓存复杂运算的结果
短视频实际上是使用内置的网络播放器来完成的。网络播放器吸收的是数据流，将数据下载下来之后经太过离音视频流，解码等流程后输出到外设设备上播放。
如果我们在打开一个视频的时候才开始下载数据的话，无疑会增加视频的打开速度（我们叫首播时间），而且播放过程中会有卡顿。所以我们的播放器中通常会设计一些缓存的组件，在未打开视频时缓存一部分视频数据，好比我们打开抖音，服务端可能一次会返回三个视频信息，我们在播放第一个视频的时候，播放器已经帮我们缓存了第二、三个视频的部分数据，如许在看第二个视频的时候就可以给用户“秒开”的感觉。
HTTP协议也是有缓存机制的。当我们第一次哀求静态的资源时，好比一张图片，服务端除了返回图片信息，在响应头里面还有一个“Etag”的字段。浏览器会缓存图片信息以及这个字段的值。当下一次再哀求这个图片的时候，浏览器发起的哀求头里面会有一个“If-None-Match”的字段，而且把缓存的“Etag”的值写进去发给服务端。服务端比对图片信息是否有变化，如果没有，则返回浏览器一个304的状态码，浏览器会继续使用缓存的图片信息。通过这种缓存协商的方式，可以减少网络传输的数据大小，从而提拔页面展示的性能。
缓存与缓冲区

缓冲和缓存只有一字之差，它们有什么区别呢？
缓存：

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

理论上可通过缓存解决所有“慢”问题，好比从磁盘随机读取数据慢，从数据库查询数据慢，只是不同场景斲丧的存储成本不同。
缓冲区则是一块临时存储数据的地区，这些数据背面会被传输到其他设备上。缓冲区更像MQ，用以弥补高速设备和低速设备通信时的速度差。好比，我们将数据写入磁盘时并不是直接刷盘，而是写到一块缓冲区里面，内核会标识这个缓冲区为脏。当经过一定时间或者脏缓冲区比例到达一定阈值时，由单独的线程把脏块刷新到硬盘上。如许避免了每次写数据都要刷盘带来的性能问题。
所以TLB的定名是有问题的，它应该是缓存而不是缓冲区。
缓存分类

静态缓存

在Web 1.0时期黑白常著名的，它一般通过生成Velocity模板或者静态HTML文件来实现静态缓存，在Nginx上部署静态缓存可以减少对于后台应用服务器的压力。例如，我们在做一些内容管理体系的时候，后台会录入很多的文章，前台在网站上展示文章内容，就像新浪，网易这种流派网站一样。
当然，我们也可以把文章录入到数据库里面，然后前端展示的时候穿透查询数据库来获取数据，但是如许会对数据库造成很大的压力。纵然我们使用分布式缓存来挡读哀求，但是对于像日均PV几十亿的大型流派网站来说，基于成本思量仍然是不划算的。
所以我们的解决思路是每篇文章在录入的时候渲染成静态页面，放置在所有的前端Nginx或者Squid等Web服务器上，如许用户在访问的时候会优先访问Web服务器上的静态页面，在对旧的文章实行一定的清算策略后，依然可以保证99%以上的缓存命中率。
这种缓存只能针对静态数据来缓存，对于动态哀求就无能为力了。那么我们如何针对动态哀求做缓存呢？这时你就需要分布式缓存了。
分布式缓存

Memcached、Redis就是分布式缓存的典型例子。它们性能强劲，通过一些分布式的方案组成集群可以突破单机的限制。所以在团体架构中，分布式缓存负担着非常重要的角色（接下来的课程我会专门针对分布式缓存，带你了解分布式缓存的使用技巧以及高可用的方案，让你能在工作中对分布式缓存运用自如）。
对于静态的资源的缓存你可以选择静态缓存，对于动态的哀求你可以选择分布式缓存，那么什么时候要思量热点本地缓存呢？
答案是当我们遇到极端的热点数据查询的时候。热点本地缓存重要部署在应用服务器的代码中，用于阻挡热点查询对于分布式缓存节点或者数据库的压力。
好比某一位明星在微博上有了热点话题，“吃瓜群众”会到他(她)的微博首页围观，这就会引发这个用户信息的热点查询。这些查询通常会命中某一个缓存节点或者某一个数据库分区，短时间内会形成极高的热点查询。
本地缓存

如HashMap，Guava Cache或者是Ehcache等，它们和应用程序部署在同一个进程中，优势是不需要跨网络调度，速度极快，所以可以来阻挡短时间内的热点查询。来看个例子。
比方说你的垂直电商体系的首页有一些保举的商品，这些商品信息是由编辑在后台录入和变动。你分析编辑录入新的商品或者变动某个商品的信息后，在页面的展示是答应有一些耽误的，好比说30秒的耽误，而且首页哀求量最大，纵然使用分布式缓存也很难抗住，所以你决定使用Guava Cache来将所有的保举商品的信息缓存起来，而且设置每隔30秒重新从数据库中加载最新的所有商品。
首先，我们初始化Guava 的Loading Cache：
CacheBuilder cacheBuilder = CacheBuilder.newBuilder().maximumSize(maxSize).recordStats(); //设置缓存最大值cacheBuilder = cacheBuilder.refreshAfterWrite(30, TimeUnit.Seconds); //设置刷新间隔LoadingCache cache = cacheBuilder.build(new CacheLoader() {    @Override    public List load(String k) throws Exception {        return productService.loadAll(); // 获取所有商品    }});获取所有商品信息时，可调用Loading Cache的get，优先从本地缓存获取商品信息，如果不存在，会使用CacheLoader中的逻辑从DB加载所有商品。
由于本地缓存部署在应用服务器，通常集群部署，当数据更新时，不能确定哪台服务器本地中了缓存，更新或删除所有服务器的缓存不是一个好的选择，所以通常会等待缓存逾期。因此，这种缓存的有用期很短，通常为分钟或秒级别，以避免返回前端脏数据。
缓存的不足

缓存重要是提拔访问速度，从而抗更高并发。那不意味着它就是银弹。

• 缓存适于读多写少，而且数据最好带有一定热点属性。因为缓存受限存储介质，不可能缓存所有数据，当数据有热点属性时，才能保证缓存命中率。好比朋友圈这种20%内容会占80%流量。所以，一旦当业务场景读少写多时或无明显热点，好比在搜索场景，每个人搜索的词都不同，无明显热点，此时缓存作用不大。
  
• 缓存会给团体体系带来复杂度，且有数据不一致风险。当更新数据库成功，更新缓存失败的场景下，缓存中就会存在脏数据。可思量使用较短逾期时间或者手动清算。
  
• 缓存通常使用内存作为存储介质，但内存并不是无穷。因此，使用缓存时要做数据存储量级评估，需斲丧极大存储成本的数据，慎用缓存。缓存一定要设置逾期时间，可保证缓存中的会是热点数据。
  
• 缓存会给运维也带来一定的成本，运维需要对缓存组件有一定的了解，排盘问题时，也多了个组件考量。
  

但缓存对性能提拔的意义毋庸置疑，架构设计时一定要把它思量在内，只是详细方案需要对缓存设计有更过细思考，最大化发挥缓存优势。
小结

缓存可以有多层，好比
静态缓存处在负载均衡层
分布式缓存处在应用层和数据库层之间
本地缓存处在应用层。
需要将哀求尽量挡在上层，因为越往下层，对于并发的承受能力越差；
缓存命中率是缓存最重要的监控项。
缓存不仅仅是一种组件的名字，更是一种设计思想，任何可以或许加快读哀求的组件和设计方案都是缓存思想的表现。
而这种加快通常是通过两种方式来实现：
使用更快的介质，如内存；
缓存复杂运算的结果，如TLB。
当你在实际工作中遇到“慢”问题，缓存就是你的第一考量。

作者：JavaEdge.
原文链接：https://blog.csdn.net/qq_33589510/article/details/120232429

听君一席话胜听一席话

转发了

转发了

转发了

转发了