系统性能提升优先法宝 | 缓存应用实践-51CTO.COM

缓存是系统性能提升优先法宝，在互联网应用系统中，屡试不爽。网上有很多资料介绍缓存理论及使用策略，本文就不再涉及了，今天简单将缓存做个归类，重点分享以前在实际业务中碰到场景以及如何使用。

接下来主要分两部分介绍：缓存分类与应用实践案例。

缓存分类

缓存一般有以下几类：客户端、浏览器、CDN缓存、NGINX缓存、应用缓存及统一缓存(如redis)。

缓存分类：用户->数据层

客户端缓存：很少使用，一般都是传统企业才会使用。把不变化或很长时间才变化的数据按一定格式存储在客户端的本地文件中，使用时通过js读取解析使用，延用了C/S结构的方式，适合数据量很大业务且技术有所不足的开发。
浏览器缓存：这种形式使用很广泛，极大地提升了用户体验，但有时会出现没及时更新导致显示“错误”的信息。把已经请求过的Web资源(如html页面，图片，js，css等)拷贝一份副本储存在浏览器中，缓存会根据进来的请求保存输出内容的副本。这种缓存带来的好处有三点：减少网络带宽消耗，降低服务器压力，减少网络延迟、加快页面打开速度，适合请求量大、静态的数据请求。
CDN缓存：在用户和服务器之间增加cache层，把数据存放到内容分发网络机房服务器中，用户请求进从最近的CDN节点获取。主要缓存图片、js及css文件，CDN需要付费，有些规模的网站才会使用。
NGINX缓存：对客户已经访问过的内容在Nginx服务器本地建立副本，达到减少Nginx服务器与后端服务器之间的网络流量。
应用缓存：在后端应用中使用缓存，如java常使用Ehcache及gauva缓存组件进行数据缓存，也可以针对特殊场景在请求中进行线程缓存。适合调用量大且应用内部方法间调用，减少网络消耗。
统一缓存：使用内存减少对数据库的直接访问，提高网站性能，如使用memcache或redis搭建缓存服务。

前四类都是在网络传输中进行数据缓存，一般研发很少会去使用，后两类在应用中缓存，在开发中经常使用，接下来介绍后两类缓存的实践案例。

实践案例

1. 热点key

场景：在大促期间，给所有活动页及频道页提供侧滑html片段数据，会有修改。

特点：数据记录少，调用量比较大(峰值400万/分钟)。

在接到需求时，***反应是使用redis进行缓存，数据更新时删除redis缓存。读取时先读取redis，缓存为空，读取DB并存放redis。

该场景是使用redis当缓存使用，存在一定风险：由于数据量少并发高时，成为热点key会集中***单个redis实例，流量上去后，性能会变差，甚至可能拖垮实例。

进一步改进本地JVM缓存，加redis缓存，JVM缓存一分种失效，回源redis及数据库。存在集中穿透缓存回源数据库，拖垮应用或数据库的情况，之前有过缓存失效，集中回源数据库的经历，结果应用服务一台台全部倒下，数据库没有压力。事后分析，数据库配置***连接数为10，外部请求超时时间为500ms，不断有新请求进来，大量请求在等待连接。***选择在JVM使用ConcurrentMap存放当DB使用，1分钟异步刷新数据。

在大促当天，页面该请求返回性能不太理想，数据返回大概73KB，使用Nginx增加gzip压缩后，数据压缩到13KB，性能提高不少。后续在Nginx增加代理缓存，性能稳定。

2. 类目中心设计

类目是电商领域最基础的数据，使用依赖的系统很多，早期是各个系统直接从数据库读取并自行缓存使用，人为给数据库增压。为了避免该情况，着手搭建类目中心，对性能及稳定要求***，类目中心服务异常不能影响使用方，类目更新后要及时同步给使用方。

经过多次讨论，确认使用三级缓存：客户端缓存、类目系统jvm缓存及统一redis缓存。

(1) 类目中心--读

客户端缓存：在对外提供的api依赖包中进行缓存封装，通过调用类目系统接口提供缓存后的服务方法。缓存数据记录失效时间，调用时发现缓存数据已失效时，更新失效时间并返回，异步请求类目中心数据刷新。若缓存没有***，回源请求类目中心。客户端会定时检测类目版本信息，若版本更新变化，客户端数据强制更新。
类目系统jvm缓存：使用jvm缓存，若有过期异步回源，统一缓存redis，穿透直接回源redis。
统一缓存redis：当DB使用，不回源数据库，并定时从数据库把数据刷新至redis中。为了避免并发刷新，使用redis实现排它锁，保证只一个任务刷新。

数据更新请求，有一定的规则：