使用缓存的场景
一般来说, 现在网站 或者 app 的整体流程可以用下图来表示. 用户从浏览器或者app 发起请求 > 到网络转发 > 到服务 > 再到数据库 , 接着再返回把请求内容呈现给用户.但是随着访问量的增大 , 访问内容的增加, 应用需要支撑更多的并发, 同时应用服务器和数据库服务器所要做的计算越来越多, 但是应用服务器的资源有限, 文件内容的读写也是有限的 . 如何利用有限的资源提高更大的吞吐量 , 那就是引入缓存 , 打破标准的流程, 在每个环节中 , 请求可以从缓存中直接获取目标数据并返回 , 从而减少应用的计算量, 提升应用的响应速度 , 让有限的资源服务更多的用户. 如下图, 缓存可以出现在 1 ~ 4 的各个环节中.
缓存的特征
命中率 = 命中数 / (命中数+ 没有命中数)
命中率越高 , 说明使用缓存的收益越好 , 应用性能越好, 响应的时间越短 , 吞吐量越高 ,抗并发的能力越强最大元素(空间)
代表缓存中可以存放的最大元素的数量 , 一旦缓存中元素的数量超过最大空间 ,是指缓存数据所在空间超过最大支持的空间, 将会触发清空策略 . 根据不同的场景合理的设置最大元素值, 可以在一定程度上提高缓存的命中率, 从而更有效的使用缓存 .清空策略
FIFOfirst in first out先进先出
最先进入缓存空间的数据 , 在缓存不够的情况下, 或者缓存数量超过最大元素的情况下 ,会被优先清除掉 , 以腾出空间缓存新的数据, 这个清除算法主要是比较缓存元素的创建时间.在数据实时性要求场景下可以使用该策略 ,优先保证最新数据可用 .LFUleast frequently used最少使用策略
该策略是根据元素的使用次数来判断 , 无论缓存元素是否过期 , 清除使用次数最少的元素来释放空间.这个策略的算法主要比较元素的命中次数.在保证高频数据有效性的场景下 , 可以使用此类策略.LRULeast Recently Used最近最少使用策略
它是指无论是否过期 , 根据元素最后一次被使用的时间戳 , 清除最远使用时间戳的元素 , 这个策略的算法主要比较元素的最近一次被get使用时间, 在热点数据的场景下较适用 , 优先保证热点数据的有效性 .- 过期时间
根据过期时间来判断 , 清理过期时间最长的元素, 还可以根据过期时间来判读, 来清理最近要过期的元素 . - 随机
随机清理元素
缓存命中率的影响因素
业务场景和业务需求
缓存适合 读多写少 的业务场景, 否则使用其意义不大,命中率会很低 .业务需求也决定了对实时性的要求, 直接影响到缓存的过期时间和更新策略,实时性要求越低就越适合缓存 .在相同 key 和相同请求数的情况下 ,缓存的时间越长, 命中率就会越高.缓存的设计(粒度和策略)
通常情况下 , 缓存的粒度越小, 命中率就会越高.缓存的容量和基础设施
缓存的容量有限, 就容易引起缓存的失效和淘汰. 目前多少的缓存框架都使用了LRU这个算法 .同时缓存的技术选型也是很重要的 .比如采用应用内置的本地缓存,就容易出现单机瓶颈 , 而采用分布式缓存 ,它就更容易扩展, 所以要做好系统容量的规划 ,并考虑是否可以扩展 , 另外不同的缓存中间件, 其效率和稳定性都是有差异的.除此之外, 还有其他的一些会影响缓存命中率 , 比如某个缓存节点挂掉的时候 , 要避免缓存失效, 并最大程度的降低影响 . 比较典型的做法就是 一致性hash算法 , 或者通过节点冗余的方式来避免这个问题 .
如何提高缓存命中率
从应用架构的角度 , 要尽可能的使得应用通过缓存来直接获得数据并避免缓存失效.当然这需要对业务需求, 缓存粒度, 缓存策略,技术选型等各个方面通盘考虑权衡的 , 尽可能聚焦在高频访问且时效性不高的热点业务上 , 通过缓存预加载, 增加存储容量, 调整缓存粒度, 更新缓存等手段来提高命中率.
缓存的应用和分类场景
目前的应用服务框架中 , 是根据缓存与应用的耦合度分为本地缓存和分布式缓存.
* 本地缓存
本地缓存是指缓存中的应用组件, 它最大的优点是应用和 cache , 是在同一个进程的内部, 请求缓存非常的快速.没有过多的网络开销等,在单应用中,不需要集群支持 , 各节点不需要互相通知的情景下, 适合使用本地缓存.
它的缺点也是显而易见的, 由于缓存和应用耦合度较高, 多个应用无法共享缓存 ,各个应用都需要单独维护自己的缓存 ,对内存也是一种浪费, 资源能节省就节省. 在实际实现中 , 都是同成员变量, 局部变量, 静态变量 来实现, 也还有一些框架 比如 Guava Cache
* 分布式缓存
它是指应用分离的缓存组件或服务, 最大的优点是自身是一个独立的应用 ,与本地应用是隔离的,多个应用可以直接共享缓存. 比如 常用的Redis