既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
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
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**
扫一扫
115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
