为什么使用缓存

一般情况下，在访问量达到一定规模后，数据库的读写会成为一个瓶颈，我们会采用一些手段来对数据库减压，让它可以正常的工作。可以考虑的手段包括读写分离、添加缓存服务器等，读写分离是为了尽量将对数据库的读写动作分开，减少互相之间的影响；添加缓存是为了读库的时候，减少直接读取数据库的动作，将查询的结果存放在缓存中，用户的请求被隔绝在数据库以外，从而减少数据库的压力。

这是一个理想状况下缓存工作的方式，但仅仅是理想

缓存穿透

所谓缓存穿透，是说用户请求在缓存系统中查找结果时候失效，接下来去后端存储系统中查找数据，这个时候，如果数据不存在，而且这个访问也比较大的情况下，大量的访问会直接命中数据库，这时候负责存储的服务器就悲剧了（如果左图），所以我们就需要做一些努力，使得当数据不存在，往缓存中写入一个标志抑或将空的查询结果存入缓存，减少这种无用的请求频繁命中数据库的情况（如右图）

也可以将确认为空或者空的查询结果存储到单独的缓存区域中。

缓存雪崩

这是另外一个问题，当系统使用的缓存发生意外(网络失败、宕机、服务挂掉、缓存集体丢失等等)之后，缓存集体失效，导致短时间内请求都到达数据库(数据存储层)，使得数据库压力山大进而crash掉。

为了预防这种情况，我们采用一下几种方式：

1、我们采用多实例的方式来保证缓存的高可用性，尽量避免当个别实例出现问题之后，引起全局缓存的问题。这类方案很多，比如memcache的一致性hash，redis的cluster机制，来避免单点的故障，这类资料可以搜索一下关于redis或者memcache的高可用方案。

2、降级机制。这个方法在很多高可用设计中可能也有描述，简单一点说就是我们将用户与用户之间，资源与资源之间进行隔离，当某一部分数据产生问题之后或者对某一部分的请求到达一个阀值之后，根据预设的机制，对请求只返回热点数据，保证客户端不会产生天窗或者说一直无法响应的问题。

3、加锁。对于到达的请求，我们用锁的机制，来尽量使它们排队处理从而减少对数据库产生并发。可以参考的锁方案有两种，一种是使用全局锁或者字符串锁等方案，是一个请求进行操作的时候，其他的请求处于等待状态，当这个请求处理完毕之后进行下一步的业务处理，但是这样的话如果一个请求挂掉，会对后面排队的请求产生影响，而且请求的处理可能不会短时间处理完毕，会导致请求阻塞的时间过长等问题，第二种方案就是在进行操作的时候，其他请求进来的时候判断是否有锁存在，如果存在直接跳过处理，返回热点数据。

需要说的是降级机制未必要放到图中这个位置，也可以放在缓存之前或其他的位置，它的主要目的是当出现问题时候隔离掉出现问题的资源不影响客户端的内容或者使一部分用户的请求无法到达真正的业务逻辑从而减少业务处理的压力。

友情链接：