redis学习-31- Redis三种缓存问题

34.缓存问题（图解：三种缓存问题）

• 在实际的业务场景中，Redis 一般和其他数据库搭配使用，用来减轻后端数据库的压力，比如和关系型数据库 MySQL 配合使用。

• Redis 会把 MySQL 中经常被查询的数据缓存起来，比如热点数据，这样当用户来访问的时候，就不需要到 MySQL 中去查询了，而是直接获取 Redis 中的缓存数据，从而降低了后端数据库的读取压力。如果说用户查询的数据 Redis 没有，此时用户的查询请求就会转到 MySQL 数据库，当 MySQL 将数据返回给客户端时，同时会将数据缓存到 Redis 中，这样用户再次读取时，就可以直接从 Redis 中获取数据。流程图如下所示：
  

• 在使用 Redis 作为缓存数据库的过程中，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。另外就是一些典型的问题，比如常见缓存穿透、缓存击穿和缓存雪崩等问题（服务器的高可用问题），本节将对这些问题做简单地说明，并且提供有效的解决方案。

34.1 缓存穿透

• 缓存穿透是指当用户查询某个数据时，Redis 中不存在该数据，也就是缓存没有命中，此时查询请求就会转向持久层数据库 MySQL，结果发现 MySQL 中也不存在该数据，MySQL 只能返回一个空对象，代表此次查询失败。如果这类请求非常多，或者用户利用这种请求进行恶意攻击，就会给 MySQL 数据库造成很大压力，甚至于崩溃，这种现象就叫缓存穿透。

jmeter，Apache的压力测试工具

• 为了避免缓存穿透问题，下面介绍两种解决方案：

34.1.1 缓存空对象

• 当 MySQL 返回空对象时， Redis 将该对象缓存起来，同时为其设置一个过期时间。当用户再次发起相同请求时，就会从缓存中拿到一个空对象，用户的请求被阻断在了缓存层，从而保护了后端数据库，但是这种做法也存在一些问题，虽然请求进不了 MSQL，但是这种策略会占用 Redis 的缓存空间。
  

• 但是这种方法会存在两个问题：
  1、如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键；
  2、即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响(如缓存没有，存储层存在了)。

34.1.2 布隆过滤器

• 布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力；布隆过滤器判定不存在的数据，那么该数据一定不存在，利用它的这一特点可以防止缓存穿透。
• 首先将用户可能会访问的热点数据存储在布隆过滤器中（也称缓存预热），当有一个用户请求到来时会先经过布隆过滤器，如果请求的数据，布隆过滤器中不存在，那么该请求将直接被拒绝，否则将继续执行查询。相较于第一种方法，用布隆过滤器方法更为高效、实用。其流程示意图如下：
  

缓存预热：是指系统启动时，提前将相关的数据加载到 Redis 缓存系统中。这样避免了用户请求的时再去加载数据。

34.2 缓存击穿

• 缓存击穿是指用户查询的数据缓存中不存在，但是后端数据库却存在，这种现象出现原因是一般是由缓存中 key 过期导致的。比如一个热点数据 key，它无时无刻都在接受大量的并发访问，如果某一时刻这个 key 突然失效了，就致使大量的并发请求进入后端数据库，导致其压力瞬间增大。这种现象被称为缓存击穿。（如微博服务器热点宕机现象）缓存击穿有两种解决方法：

• 1.改变过期时间,热点数据永不过期。从缓存层面来看，没有设置过期时间，所以不会出现热点ky过期后产生的问题。

• 2.分布式锁（互斥锁）:在击穿缓存层到存储层这一阶段采用分布式锁的方法，重新设计缓存的使用方式，过程如下：

  • 上锁：当我们通过 key 去查询数据时，首先查询缓存，如果没有，就通过分布式锁对该访问进程进行加锁，第一个获取锁的进程进入后端数据库查询，并将查询结果缓到Redis 中。这样保证了对于每个key同时只有一个线程去查询后端服务
  • 解锁：当其他进程发现锁被某个进程占用时没有获得分布式锁的权限，就进入等待状态，直至解锁后，其余进程再依次访问被缓存的 key。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

34.3 缓存雪崩

• 缓存雪崩是指缓存中大批量的 key 同时过期或服务器宕机，而此时数据访问量又非常大，从而导致后端数据库压力突然暴增，甚至会挂掉，这种现象被称为缓存雪崩。它和缓存击穿不同，缓存击穿是在并发量特别大时，某一个热点 key 突然过期，而缓存雪崩则是大量的 key 同时过期，因此它们根本不是一个量级。

• 产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。
  

• 其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。（淘宝：双十一会停掉一些服务来保障主要的服务高可用）

• 解决方案:

  • 缓存雪崩和缓存击穿有相似之处，所以也可以采用热点数据永不过期的方法，来减少大批量的 key 同时过期。
  • redis高可用：既然redis有可能挂掉，那多增设几台redis,这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。（异地多活)
  • 限流降级：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。还有即停掉一些服务保障其他服务可用
  • 数据预热：数据加热的含义就是在正式部署之前，先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间，让缓存失效的时间点尽量均匀，避免 key 集中过期。

下一篇：redis学习-32-Java使用Redis(Jedis)