缓存的三个问题

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

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

缓存命中率过低

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

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

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

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

特例一：分散攻击

有时候系统正常情况下是存在热点数据的，但突然有一天出现大量的分散请求，导致缓存命中率直线下降。这些异常的请求可以看作是有意的攻击行为，目的就是让系统无法响应。

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

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

特例二：无效的 key

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

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

大量缓存项同时刷新

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

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

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

出现这个现象的原因是设计上的不合理。当一个缓存正在刷新时，访问该缓存项的其他线程应该等待刷新完毕，这样它们就可以直接从缓存获得结果了。线程同步当然是用锁。如果是分布式系统，那就用分布式锁。