缓存的三个问题

缓存的做用是在内存中临时存储来自外部系统（如数据库）的数据，以便让请求更快的获得响应。若是请求数据在缓存中不存在，或者已经超时失效，那么也要从外部系统查询，而后放入缓存中，这个过程叫刷新缓存。

这是缓存的基本使用逻辑，可是实际当中可能出现三种异常状况，它们会致使缓存起不到预期的使用效果，以致于系统性能明显降低。

缓存命中率太低

缓存命中率指的是从缓存中找到数据的请求占全部请求的比重。例如 100 个请求当中有 90 个请求的结果能够直接从缓存中得到，那么命中率就是 90%。剩下 10% 的请求就要从外部系统查询数据，填入缓存，而后再返回。

什么状况下缓存命中率高呢？请求的数据比较集中的时候，例如 80% 的请求集中在 20% 的数据上，这部分数据也被称做热点之类的。热点越热，缓存命中率越高。

所以之因此出现缓存命中率太低，天然就是由于热点不够热，请求的数据很是分散。命中率太低的后果就是不少请求的数据仍需从外部系统查询，假如是数据库的话，数据库的压力就会很是大，同时系统的响应也明显变慢。

要缓解缓存命中率太低的问题，最直接的办法固然是加大缓存。本地缓存不够，就用分布式缓存，多台机器分开存储。

特例一：分散攻击

有时候系统正常状况下是存在热点数据的，但忽然有一天出现大量的分散请求，致使缓存命中率直线降低。这些异常的请求能够看做是有意的攻击行为，目的就是让系统没法响应。

而遇到攻击行为的话，加大缓存多是徒劳的，这时候须要去识别请求，对于被归类为攻击的请求主动延长响应时间，甚至拒绝返回结果。

好比说一个论坛，忽然遇到大量请求，均匀的访问五年内的帖子内容，致使数据库负载很大，此时能够将访问老帖子的请求（帖子ID一般是递增的，ID越小表示发帖时间越久）返回时间适当延长，好比延长到五分钟。不过使用这种作法时千万不要简单的暂停线程，这会致使没有多余的线程来处理正常的请求。

特例二：无效的 key

有时候系统收到大量请求，这些请求的数据非但缓存中没有，连数据库也没有，那么每一个请求不但由于缓存未命中而去查询数据库，并且由于数据库没有记录而没法填充到缓存。这是更加恶劣的状况。

遇到这种状况，一样须要鉴别无效的请求。对于 key 自增的状况，能够经过值范围来鉴别；而对于使用 UUID 的状况，就须要低成本的鉴别方式，布隆过滤器是一个选择。

大量缓存项同时刷新

缓存一般都是存在失效时间的，须要避免的一种状况就是大量缓存项在同一个时间点失效，若是此时对这些数据的请求量大，那么这些请求就会同时去刷新各自的缓存，这就将压力传递到了外部系统上。避免这种状况的办法就是在预约的失效时间基础上加上一个随机值，以错开缓存项的失效时间。

大量请求刷新同一个缓存项

一个请求遇到缓存失效，因而去刷新缓存，而在这个过程当中又有大量请求来访问正在刷新的缓存项，致使该缓存项完成本次刷新后，又马上被另外一个线程刷新，实质上每一个请求都由于缓存未命中而去访问了外部系统。

出现这个现象的缘由是设计上的不合理。当一个缓存正在刷新时，访问该缓存项的其余线程应该等待刷新完毕，这样它们就能够直接从缓存得到结果了。线程同步固然是用锁。若是是分布式系统，那就用分布式锁。