Redis应用问题

前言

用户的数据一般都是存储于数据库中，数据库的数据是落在磁盘上的，磁盘的读写速度可以说是计算机里硬件中最慢的了。

当用户的请求，都访问数据库的话，请求数量一上来，数据库很容易就崩溃，所以为了避免用户直接访问数据库，会用Redis作为缓存层。

Redis是内存数据库，将数据库的数据缓存在Redis中，相当于数据缓存在内存中，内存的读写速度比硬盘快好几个数量级，这也大大提高了系统性能。

引入了缓存层，随之而来的是有关缓存异常的一些问题：缓存穿透、缓存击穿、缓存雪崩、缓存颠簸、缓存预热、缓存降级…而前三个也正是有些企业面试经常考察的问题。

缓存穿透

概念

缓存层和数据库中都没有的数据，而用户不断发起请求，导致请求在访问缓存时，发现缓存缺失，再去访问数据库，如果从数据库中查不到该数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端持久的意义。

而我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。

造成原因

自身业务代码或者数据出现问题（例如：set 和 get 的key不一致，数据被误删除）
一些恶意攻击、爬虫等造成大量空命中（爬取线上商城商品数据，超大循环递增商品的ID）

解决方案

一、非法请求的限制

当有大量恶意请求访问不存在的数据时，也会发生缓存穿透，因此在API入口处我们要判断请求参数是否合理，请求参数是否含有非法字符、请求字段是否存在，如果判断出是恶意请求就直接返回错误，避免进一步访问缓存层和数据库。

二、缓存空对象

缓存空对象：是指在持久层没有命中的情况下，对key进行set （key,null）

缓存空对象会有两个问题：

第一，value为null不代表不占用内存空间，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。

第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。

例如过期时间设置为5分钟，如果此时存储层添加了这个数据，那这段时间内就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象

三、布隆过滤器(Bloom Filter)拦截

布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数，其实也可以说是由初始值都为0的位图数组和N个哈希函数两部分组成的。布隆过滤器可以用于检索一个元素是否在一个集合中。

优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

在写入数据库数据时，将存在的key使用布隆过滤器标记一下，然后在用户请求到来时，业务线程确认缓存失效后，可以通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在。

即使发生了缓存穿透，大量请求只会查询Redis和布隆过滤器，而不会查询数据库，这就拦截了很多注定没有结果的查询，降低了数据库的负载，保证了数据库正常运行。

布隆过滤器会通过3个操作完成标记：

使用N个哈希函数分别对数据做哈希计算，得到N个哈希值；
将第一步得到的N个哈希值对位图数组的长度取模，得到每个哈希值在位图数组的对应位置；
将每个哈希值在位图数组的对应位置的值设置为1；

举个栗子：假设有一个位图数组长度为 8，哈希函数 3 个的布隆过滤器。

布隆过滤器例子

在数据库写入数据 x 后，把数据 x 标记在布隆过滤器时，数据 x 会被 3 个哈希函数分别计算出 3 个哈希值，然后在对这 3 个哈希值对 8 取模，假设取模的结果为 1、4、6，然后把位图数组的第 1、4、6 位置的值设置为 1。当应用要查询数据 x 是否数据库时，通过布隆过滤器只要查到位图数组的第 1、4、6 位置的值是否全为 1，只要有一个为 0，就认为数据 x 不在数据库中。

布隆过滤器由于是基于哈希函数实现查找的，高效查找的同时存在哈希冲突的可能性，比如数据 x 和数据 y 可能都落在第 1、4、6 位置，而事实上，可能数据库中并不存在数据 y，存在误判的情况。

所以，查询布隆过滤器说数据存在，并不一定证明数据库中存在这个数据，但是查询到数据不存在，数据库中一定就不存在这个数据。虽有一定的误识别率，但没有识别错误的情形。

布隆过滤器适用场景：爬虫系统url去重、垃圾邮件过滤、黑名单…

缓存击穿

概念

存在某个热点数据key，例如商城秒杀活动、热搜等等。

用户大并发集中对这一个key进行访问，缓存层在不停地扛着大并发，而当这个 key 在失效过期的瞬间，持续的大并发就会穿破缓存层，直接访问数据库，此时就像在一个完好无损的桶上凿开了一个洞。

当发生缓存击穿的时候，数据库的查询压力会倍增，导致大量的请求阻塞。

解决方案

一、预先设置热点数据

在Redis高峰访问之前，把一些热点数据提前存入redis中，增加热点数据key的过期时间

二、实时调整

现场监控哪些数据被频繁访问，实时调整key的过期时间

三、永不过期

不给热点数据设置过期时间，若数据需要更新的话，可以在后台开启一个异步线程，发现过期的 key 直接重写缓存即可

四、分布式互斥锁

当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里），当缓存构建完成后，再释放锁。未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。

实现互斥锁的时候，最好设置超时时间，不然第一个请求拿到了锁，然后这个请求发生了某种意外而一直阻塞，一直不释放锁，这时其他请求也一直拿不到锁，整个系统就会出现无响应现象。

1 2	setex <key> <second> <value> //上锁并设置过期时间 set <key> <value> nx ex 10 //nx: 上锁, ex: 过期时间, 10: 过期时间为10秒

优点：较好地降低后端存储负载，并在一致性上做得比较好。

缺点：当缓存失效的时候，同一时间只有一个线程读数据库然后回写缓存，其他线程都处于阻塞状态。如果是高并发场景，大量线程阻塞会降低吞吐量。

关于穿透与击穿的一些小知识
学完上面的缓存穿透与缓存击穿，有些人可能时间久了容易忘记（记忆力好的可以忽略），况且两个词字面上看也有点相近（小声bb），于是就去查了一些资料。
穿透，本义可指：贯穿，经过，通过；
击穿，第一联想是击穿电压，电击穿等等，其实大多也是指在高压力下的破坏和穿孔现象。
单看两词，意思相近，但主要区别在于所受的环境压力。

缓存雪崩

概念

与缓存击穿相似，但区别在于缓存雪崩针对大量key缓存，而缓存击穿则则是针对某个key。

由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不可用（宕机）或者大量缓存由于过期时间相同在同一时间段失效（大批key失效/热点数据失效），大量请求直接到达存储层，存储层压力过大导致系统雪崩。

同一时间大面积失效，那一瞬间Redis跟没有一样，那这个数量级别的请求直接打到数据库几乎是灾难性的。

造成原因

大量数据同时过期
Redis故障宕机

解决方案

针对大量数据同时过期

一、均匀设置过期时间

预防大面积的 key 同时失效，可以给不同的 key 过期时间加上随机值，让缓存失效的时间点尽量均匀，这样可以保证数据不会在同一时间大面积失效。

二、分布式互斥锁

保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。与缓存击穿的措施相似。

三、双key策略

对缓存数据可以使用两个 key，一个是主 key，会设置过期时间，一个是备 key，不会设置过期，它们只是 key 不一样，但是 value 值是一样的，相当于给缓存数据做了个副本。

当业务线程访问不到主 key 的缓存数据时，就直接返回备 key 的缓存数据，然后在更新缓存的时候，同时更新主 key 和备 key 的数据。

四、后台更新缓存

业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新。

事实上，缓存数据不设置有效期，并不是意味着数据一直能在内存里，因为当系统内存紧张的时候，有些缓存数据会被“淘汰”，而在缓存被“淘汰”到下一次后台定时更新缓存的这段时间内，业务线程读取缓存失败就返回空值，业务的视角就以为是数据丢失了。

如何解决上面的问题呢？

后台线程不仅负责定时更新缓存，而且也负责频繁地检测缓存是否有效，检测到缓存失效了，可能原因是系统紧张而被淘汰的，于是就要马上从数据库读取数据，并更新到缓存。

这种方式的检测时间间隔不能太长，太长也导致用户获取的数据是一个空值而不是真正的数据，所以检测的间隔最好是毫秒级的，但是总归是有个间隔时间，用户体验一般。
在业务线程发现缓存数据失效后（缓存数据被淘汰），通过消息队列发送一条消息通知后台线程更新缓存，后台线程收到消息后，在更新缓存前可以判断缓存是否存在，存在就不执行更新缓存操作；不存在就读取数据库数据，并将数据加载到缓存。

这种方式相比第一种方式缓存的更新会更及时，用户体验也比较好。

针对Redis故障宕机

一、服务熔断或请求限流机制

当Redis故障宕机而导致缓存雪崩问题时，我们可以启动服务熔断机制，暂停业务应用对缓存服务的访问，直接返回错误，不用再继续访问数据库，从而降低对数据库的访问压力，保证数据库系统的正常运行，然后等到 Redis 恢复正常后，再允许业务应用访问缓存服务。

服务熔断机制是保护数据库的正常允许，但是暂停了业务应用访问缓存服务系统，全部业务都无法正常工作。

为了减少对业务的影响，我们可以启用请求限流机制，只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务，等到 Redis 恢复正常并把缓存预热完后，再解除请求限流的机制。

二、构建Redis缓存高可靠集群

服务熔断或请求限流机制是缓存雪崩发生后的应对方案，我们最好通过主从节点的方式构建 Redis 缓存高可靠集群。

如果 Redis 缓存的主节点故障宕机，从节点可以切换成为主节点，继续提供缓存服务，避免了由于 Redis 故障宕机而导致的缓存雪崩问题。

缓存颠簸

缓存颠簸，也被称为“缓存抖动”，可以看作一种比“雪崩”更轻微的故障，但是也会在一段时间内对系统造成冲击和性能影响，一般是由缓存节点故障导致的。

业内推荐的做法是通过一致性Hash算法来解决问题。

缓存预热

即系统上线后，先将相关的数据构建到缓存中，这样就可以避免用户请求的时候直接查库。

这部分预热的数据主要取决于访问量和数据量大小。如果数据的访问量不大的话，那么就没必要做预热，都没什么多少请求了，直接按正常的缓存读取流程执行就好。

访问量大的话，也要看数据的大小来做预热措施。

数据量不大的时候，系统启动的时候进行加载缓存动作，这种数据一般可以是电商首页的运营位之类的信息；
数据量大的时候，设置一个定时任务脚本，进行缓存的刷新；
数据量太大的时候，优先保证热点数据进行提前加载到缓存，并且确保访问期间不能更改缓存，比如用定时器在秒杀活动前30分钟就把商品信息之类的刷新到缓存，同时规定后台运营人员不能在秒杀期间更改商品属性。