特别推荐:系统性能提升优先法宝 缓存应用实践
更新时间:2019-06-26 04:47:54?点击数:242?

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

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

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

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

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

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

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

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

上一篇:极客荐 用好这几个在线% 的工作都能在浏览器中完成

下一篇:2019国家公务员考试报名照片上传出现“URL出错”是什么原因?