前言
缓存应该是技术人员最常见的一个词了, 但是或许不是所有人都能准确的说出缓存本质是什么, 又适用于什么情况, 可能遇到哪些问题, 应该怎么来解决. 下面我就分三篇文章来给大家详细介绍下缓存相关的知识. 疏漏不足之处, 也请指正, 不胜感激.
《缓存那些事之初识缓存》
《缓存那些事之缓存更新, 失效以及内存淘汰策略》
《缓存那些事之常见问题与解决方案》
什么是缓存
要了解缓存, 首先要知道缓存的本质是什么. 简单来说, 缓存是目标资源的备份, 它是一种快速响应的技术, 主要用于消除请求方和提供方性能上的差异, 提升系统的总体性能. 最早是 CPU 高速缓存, 用于减少访问内存所需平均时间, 后面拓展到了计算机领域的各个方面.
举个例子, 我们常见的浏览器缓存, 可以把远程网络请求数据保存在本地, 这样下次请求数据的时候就不用再次访问远程服务器, 而是直接通过本地缓存获取到目标资源, 从而大大减少对服务器的压力, 提升系统总体性能.
这里要注意的是, 缓存是目标资源的副本, 所以, 事实上 cookie,session 不是缓存, 而是存储, 因为它们并不是其他资源的副本. 它们的目的也不是为了平衡系统性能上的差异, 而是起到数据存储的作用.
缓存的原理
我们知道 CPU 的计算速度通常不是软件执行的瓶颈, IO 的速度会更大地影响软件执行的速度, 从 "近" 到 "远", 一般有以下几个场景:
访问内存
访问磁盘
访问网络
软件设计的性能提升, 都是想办法使进程更靠近数据, 减少数据在慢速介质中的传输. 另外木桶效应也告诉我们, 系统的整体性能总受限于最差的一个地方. 所以如果我们可以减少消耗大的操作, 或者把消耗大的操作改成消耗小的操作 (例如访问网络改成访问磁盘), 就能有效的提升系统的性能. 而缓存技术就是为了实现这一目标而出现的.
总体而言, 访问缓存相比于直接访问目标资源消耗的时间和性能更少. 例如上面浏览器缓存的例子, 如果没有浏览器缓存, 我们需要经过:
网络请求
访问磁盘获取数据
网络请求返回数据
而有了浏览器缓存之后呢, 我们只需要经过: 访问磁盘获取数据即可, 这样大大加快了页面的响应速度, 服务器也能为更多的客户端服务.
缓存分类
缓存其实一种通用技术, 存在计算机领域的各个层级, 例如 CPU 缓存, 文件缓存, 网络请求中的缓存, 应用缓存, 服务端缓存等等. 其原理和实质非常相似, 但是又有所不同, 下面介绍的内容是基于服务端缓存, 例如 Redis.
使用场景
使用缓存也不是只有好处没有坏处的地方, 事实上, 使用缓存会引入的一定的技术复杂度. 因此在我们使用缓存之前, 首先最重要的就是确认项目是否真的需要缓存, 以及哪些数据适合使用缓存.
缓存本身就是为了解决系统性能最差的一块木板, 从而提升系统整体性能, 所以如果我们的系统还没有达到受限于某一块的性能而无法再提升性能的地步, 那可能还不需要引入缓存技术. 简单来说, 就是低并发低流量的应用引入缓存并不会带来性能的显著提升, 反而会带来应用的复杂度提升以及极高的运维成本, 而在高并发大流量的业务场景中引入缓存相对而言收益会更高.
那么哪些数据适合使用缓存呢? 一般来说, 具有以下性质的数据适合做缓存:
数据可能会被频繁的被使用且变化频率不高
数据本身不大
数据一致性要求不高
事实上也很容易理解, 缓存也是有成本的, 被频繁使用的数据我们使用缓存才有意义, 如果一个数据一年才使用一次, 那使用缓存就很浪费了. 而变化频率不高让我们不需要经常更新缓存, 如果一个数据频繁的需要被更新, 那缓存也会经常用不上 (缓存更新策略决定的, 更新数据的时候要让对应的缓存失效, 后续文章会介绍到).
另外如果数据本身很大, 那我们可以缓存的数据量也会很少, 同时存取也会更耗时, 这样的缓存使用起来的效率也不高.
最后, 缓存毕竟是目标资源的备份, 也就是说缓存有可能是和目标资源不一致的, 有可能是数据还没更新到缓存, 也有可能是脏数据. 如果是对数据一致性要求非常高的数据, 那也不适合使用缓存. 当然缓存也可以做到非常高的一致性, 但是那就需要引入其他技术了, 例如分布式事务提交, 这就又会引入更多的技术复杂度, 需要根据实际情况去选择了.
如何来评价缓存系统设计
如果我们决定要使用缓存技术了, 那么如何来判断我们的缓存系统设计的好不好的, 主要看命中率.
命中率 = 返回正确结果数 / 请求缓存次数. 我们使用缓存的目的就是为了用缓存来补足系统薄弱的地方, 因此缓存命中率是衡量缓存有效性的重要指标. 只有命中率高, 才说明我们缓存被有效使用到了, 那才能说我们的缓存系统的设计是合理且高效的.
参考链接
《什么时候需要自己搭建缓存服务》
Enjoy it !
如果觉得文章对你有用, 可以赞助我喝杯咖啡~
来源: http://www.jianshu.com/p/374f9f385e2d