缓存雪崩造成的原因是因为我们在做缓存时为了保证内存利用率以及为了保证缓存中的数据与数据库中的数据一致性，一般在写入数据时都会给定一个过期时间，而就是因为过期时间的设置有可能导致大量的key在同一时间内全部失效，此时来了大量请求访问这些key，而Redis中却没有这些数据，从而导致所有请求直接落入数据库查询，造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃。

可以看到，发生缓存雪崩有两个原因：

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

不同的诱因，应对的策略也会不同。

大量数据同时过期

针对大量数据同时过期而引发的缓存雪崩问题，常见的应对方法有下面这几种：

均匀设置过期时间；
互斥锁；
设置热点数据永不过期；

1. 均匀设置过期时间

如果要给缓存数据设置过期时间，应该避免将大量的数据设置成同一个过期时间。我们可以在对缓存数据设置过期时间时，给这些数据的过期时间加上一个随机数，这样就保证数据不会在同一时间过期。

2. 互斥锁

当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里），当缓存构建完成后，再释放锁。未能获取互斥锁的请求，等待锁释放后重新读取缓存。（性能会受到很大的影响，不建议，因为使用缓存就是为了性能）

3.设置热点数据永不过期：

设置热点数据永不过期，避免热点数据的失效导致大量的相同请求落入DB；缓存数据不设置有效期，并不是意味着数据一直能在内存里，因为当系统内存紧张的时候，有些缓存数据会被“淘汰” 。

Redis 故障宕机

针对 Redis 故障宕机而引发的缓存雪崩问题，常见的应对方法有下面这几种：

服务熔断或请求限流机制；
构建 Redis 缓存高可靠集群；

注：也可以从恢复角度出发：

恢复角度：Redis 的 RDB+AOF组合持久化策略，方便redis宕机后及时恢复数据

缓存击穿

缓存击穿和缓存雪崩有点类似，都是由于请求的key过期导致的问题，但是不同点在于失效key的数量，对于雪崩而言指的是大量的key失效导致大量请求落入数据库，而对于击穿而言，指的是某一个热点key突然过期，而这个时候又突然又大量的请求来查询此热点key，但是在Redis中却并没有查询到结果从而导致所有请求全部进入数据库，导致在这个时刻数据库直接被打穿。

应对缓存击穿可以采取前面说到两种方案：

互斥锁方案，保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，等待锁释放后重新读取缓存。
设置热点数据永不过期，避免热点数据的失效导致大量的相同请求落入DB；缓存数据不设置有效期，并不是意味着数据一直能在内存里，因为当系统内存紧张的时候，有些缓存数据会被“淘汰” 。

Redis异常：如何解决缓存雪崩、击穿、穿透？ – 掘金

现在的项目是如何解决Redis缓存穿透、缓存雪崩、缓存击穿的？

本地缓存 + 限流 + 合理的缓存失效时间，足以抗住整个秒杀环节；对于redis集群高可用、持久化策略还没有在项目中实现。

Redis中所有对于数据库的存或者取都需要经过网络的IO达到对应的redisService上（I/0开销是耗时的主要原因：因为redis的数据存在内存上），所以使用本地热点缓存；本地热点缓存只有热点数据才可以进入，热点数据每秒钟的访问量是非常大的，这样可以减少服务端到redis中取数据对应的网络开销，也可以减少redisService的压力。

设置合理的失效时间避免Redis缓存和本地缓存同时回源。

面试题：Rdeis线程安全问题

关于取数据判断是否为null的逻辑上面，如果在高并发场景下，不加锁，是否会有线程安全问题，是否该加个双重检查锁？

答：无需加锁，因为用缓存本身就没有必要保证一定不能脏读，加了锁反而影响性能，就体现不出来做缓存的任何意义

《【面试突击】— Redis篇》–Redis的线程模型了解吗？为啥单线程效率还这么高？

面试题：谈谈你对Redis的理解？

Redis是C语言编写的一个基于内存的高性能键值对（key-value）的NoSQL数据库，一般用于架设在Java程序与数据库之间用作缓存层，为了防止DB磁盘IO效率过低造成的请求阻塞、响应缓慢等问题，用来弥补DB与Java程序之间的性能差距，同时，也可以在DB吞吐跟不上系统并发量时，避免请求直接落入DB从而起到保护DB的作用。
而Redis一般除了缓存DB数据之外还可以利用它丰富的数据类型及指令来实现一些其他功能，比如：计数器、用户在线状态、排行榜、session存储等，同时Redis的性能也非常可观，通过官方给出的数据显示能够达到10w/s的QPS处理，但是在生产环境的实测结果大概读取QPS在7-9w/s，写入QPS在6-8w/s左右（注：与机器性能也有关），同时Redis也提供事务、持久化、高可用等一些机制的支持。

面试题：Redis的基本数据类型

Redis数据类型在之前是五种，但是现在的版本中存在九种，分别为常见的五种：字符串（string）、散列（hash）、列表（list）、集合（set）、有序集合（sorted sets）以及后续的四种数据类型：bitmaps、hyperloglogs、地理空间（geospatial）、消息（Streams），不过无论是哪种数据类型Redis都不会直接将它放在内存中存储，而是转而内部使用RedisObject来存储以及表示所有类型的key-value（如下图）：

Redis内部使用一个RedisObject对象来表示所有的key和value，RedisObject最主要的信息如上图所示：type表示一个value对象具体是何种数据类型，encoding是不同数据类型在Redis内部的存储方式。比如：type=string表示value存储的是一个普通字符串，那么encoding可以是raw或者int，而关于其他数据类型的内部编码实现如下图：

Redis的基本数据类型以及它们的应用场景：

类型	描述	特性	场景
string	二进制安全	可以存储任何元素（数字、字符、音视频、图片、对象…..）	计数器、分布式锁、字符缓存、分布式ID生成、session共享、秒杀token、IP限流等
hash	键值对存储，类似于Map集合	适合存储对象，可以将对象属性一个个存储，更新时也可以更新单个属性，操作某一个字段	对象缓存、购物车等
list	双向链表	增删快	栈、队列、有限集合、消息队列、消息推送、阻塞队列等
set	元素不能重复，每次获取无序	添加、删除、查找的复杂度都是O(1)，提供了求交集、并集、差集的操作	抽奖活动、朋友圈点赞、用户（微博好友）关注、相关关注、共同关注、好友推荐（可能认识的人）等
sorted set	有序集合，每个元素有一个对应的分数，不允许元素重复	基于分数进行排序，如果分数相等，以key值的 ascii 值进行排序	商品评价标签（好评、中评、差评等）、排行榜等
bitmaps	Bitmaps是一个字节由 8 个二进制位组成	在字符串类型上面定义的位操作	在线用户统计、用户访问统计、用户点击统计等
hyperloglog	Redis2.8.9版本添加了 HyperLogLog结构。Redis HyperLogLog是用来做基数统计的算法。	用于进行基数统计，不是集合，不保存数据，只记录数量而不是具体数据	统计独立UV等
geospatial	Redis3.2版本新增的数据类型：GEO对地理位置的支持	以将用户给定的地理位置信息储存起来，并对这些信息进行操作	地理位置计算
stream	Redis5.0之后新增的数据类型	支持发布订阅，一对多消费	消息队列

面试的时候说下常见的五种就行，其它的自己也没深入学习。

面试题：redis内存淘汰机制

redis会在每次处理redis命令的时候判断当前redis是否达到了内存的最大限
制(
通过maxmemory配置)
，如
果达到
限制
就会触发内存淘汰机制
，则使用对应的算法去处理需要删除的key。

maxmemory-policy：参数配置淘汰策略。maxmemory：限制内存大小(
当内存已使用率到达，则开始清理缓存)。

Redis
在5.0之前为我们提供了六种淘汰策略，而5.0为我们提供了八种，但是大体上来说这些
lru、lfu、random、ttl
四种类型，如下：

策略	概述
volatile-lru	从已设置过期时间的key中挑选最近最少使用的淘汰，没有设置过期时间的key不会被淘汰，这样就可以在增加内存空间的同时保证需要持久化的数据不会丢失。
volatile-ttl	从已设置过期时间的key中挑选将要过期的数据淘汰，ttl值越大越优先被淘汰。
volatile-random	从已设置过期时间的key中任意选择数据淘汰
volatile-lfu	从已设置过期时间的key挑选使用频率最低的数据淘汰
allkeys-lru	从key中挑选最近最少使用的数据淘汰，该策略要淘汰的key面向的是全体key集合，而非过期的key集合（应用最广泛的策略）。
allkeys-lfu	从key中挑选使用频率最低的数据淘汰
allkeys-random	从key中随机选择数据淘汰
no-enviction	是当内存不足以容纳新入数据时，新写入操作就会报错，请求可以继续进行，线上任务也不能持续进行，采用no-enviction策略可以保证数据不被丢失；默认策略。

自己项目中Redis用的默认的no-enviction，设置了10分钟的缓存失效时间，本地热点缓存设置了LRU缓存策略；

由于设置redis失效时间会消耗额外的内存，如果计划避免Redis内存在此项上的浪费，可以选用allkeys-lru策略，这样就可以不再设置过期时间，高效利用内存了。

LRU是Least Recently Used的缩写，即最近最少使用。LRU源于操作系统的一种页面置换算法，选择最近最久未使用的页面予以淘汰。在Redis里，就是选择最近最久未使用的key进行删除。

面试题：Redis持久化机制

Redis的确是将数据存储在内存的，但是也会有相关的持久化机制将内存持久化备份到磁盘，以便于重启时数据能够重新恢复到内存中，避免数据丢失的风险。而Redis持久化机制由三种，在4.X版本之前Redis只支持AOF以及RDB两种形式持久化，但是因为AOF与RDB都存在各自的缺陷，所以在4.x版本之后Redis还提供一种新的持久化机制：混合型持久化（但是最终生成的文件还是.AOF）。

RDB

RDB
持久化把内存中当前进程的数据生成快照（
.rdb）文件保存到硬盘的过程，有手动触发和自动触发；

手动触发时会
阻塞当前
Redis
，直到
RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它

自动触发：Redis 进程创建子进程，由子进程完成持久化，阻塞时间很短（微秒级），是
save的优化，在执行
Redis-cli shutdown
关闭
Redis服务时或执行
flushall
命令时，如果没有开启
AOF
持久化，自动执行
bgsave

而且RDB 是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，重启时加载这个文件达到数据恢复。

RDB优缺点：

优点：使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 Redis 的高性能；而且RDB文件存储的是压缩的二进制文件，适用于备份、全量复制，可用于灾难备份，同时RDB文件的加载速度远超于AOF文件。
缺点：RDB是间隔一段时间进行持久化，如果持久化之间的时间内发生故障，会出现数据丢失。所以这种方式更适合数据要求不严谨的时候，因为RDB无法做到实时持久化，而且每次都要创建子进程，频繁创建成本过高；备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（需要的内存是原本的两倍）；还有一点，RDB文件保存的二进制文件存在新老版本不兼容的问题。

AOF

AOF
持久化方式能很好的解决
RDB持久化方式造成的数据丢失，
AOF持久化到硬盘中的并不是内存中的数据快照，而是记录写入命令(和
MySQL的
binlog(归档日志)日志一样)

AOF持久化机制优缺点：

优点：可以保证数据丢失风险降到最低，数据能够
保证是最新的，持久化是后台线程在处理，所以对于处理客户端请求的线程并不影响。
缺点：文件体积由于保存的是所有命令会比RDB大上很多，而且数据恢复时也需要重新执行指令，在重启时恢复数据的时间往往会慢很多。虽然持久化并不是共用处理客户端请求线程的资源来处理的，但是这两个线程还是在共享同一台机器的资源，所以在高并发场景下也会一定受到影响。

面试题：Redis写时复制思想的体现：

简单总结一下 Redis 为什么在使用 RDB 进行快照时会通过子进程的方式(注意只有两个线程)进行实现：

在 fork 函数调用时，父进程和子进程会被分配到不同的虚拟内存空间中，所以在两个进程看来它们访问的是不同的内存。

fork子进程时，我们只为其生成虚拟空间，但是并不先为每个部分分配真实的物理空间，而是让每个虚拟空间部分仍然指向父进程的物理空间，所以父子进程共享了物理上的内存空间。只有当父进程或子进程修改相应的共享内存空间时，对被写入的内存共享才结束同时会为子进程分配真实物理空间，并把父进程的物理空间内容进行复制。这就是所谓的写时复制，即把内存的复制延迟到了内存写入的时刻。减少了快照持久化时的内存消耗同时节省了不少时间。

注意，
父子进程共享的空间粒度是页，共享的内存才会以页为单位进行拷贝，父进程会保留原有的物理空间，而子进程会使用拷贝后的新物理空间；
这样，如果当子进程运行期间，父子进程都没有修改数据，这也就避免了大量拷贝内存而带来的
时间消耗和空间占用问题。

Redis写时复制的好处：

写时拷贝的主要作用就是将拷贝推迟到写操作真正发生时，这也就避免了大量无意义的拷贝操作。

在 Redis 作为中间件服务过程中，子进程只会读取共享内存中的数据，它并不会执行任何写操作，只有父进程会在写入时才会触发写时复制机制，而对于大多数的 Redis 服务或者数据库，写请求往往都是远小于读请求的，所以使用 fork 加上写时拷贝这一机制能够带来非常好的性能，也让自动触发这一操作的实现变得非常简单。

Redis写时拷贝（COW）总结 – 掘金 —这篇文章把redis写时复制写的很厉害

Redis持久化时如何判断数据过期？

RDB

从内存数据库持久化数据到RDB文件：持久化key之前，会检查是否过期，过期的key不进入RDB文件；

从RDB文件恢复数据到内存数据库：数据载入数据库之前，会对key先进行过期检查，如果过期，不导入数据库（主库情况）。

AOF

从内存数据库持久化数据到AOF文件：

当key过期后，还没有被删除，此时进行执行持久化操作（该key是不会进入AOF文件的，因为没有发生修改命令）

当key过期后，在发生删除操作时，程序会向aof文件追加一条删除命令（在将来的以AOF文件恢复数据的时候该过期的键就会被删掉）

AOF重写：

重写时，会先判断key是否过期，已过期的key不会重写到AOF文件

项目中Redis的持久化机制

项目中使用默认的RDB方式；
项目中考虑到了
Redis
中仅仅只是用来做缓存
，虽然
RDB
因为并不是实时的持久化，会出现数据丢失，但项目的场景是可以容忍一定的数据丢失的。

面试题：Redis为什么快呢？

Redis到底有多快？

Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。

Redis快的原因嘛其实可以从多个维度来看待：

一、Redis完全基于内存
二、Redis整个结构类似于HashMap，查找和操作复杂度为O(1)，不需要和MySQL查找数据一样需要产生随机磁盘IO或者全表查询
三、Redis对于客户端的请求处理是单线程的，采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
四、底层采用select/epoll多路复用的高效非阻塞IO模型
五、客户端通信协议采用RESP，简单易读，避免了复杂请求的解析开销

面试题：redis 的线程模型是什么？为什么 redis 单线程却能支撑高并发？

多路 I/O 复用模型

多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。

采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），同时
非阻塞 IO 意味着线程在读写 IO 时可以不必再阻塞了，读写可以瞬间完成然后线程可以继续干别的事了。且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量。

为什么Redis是单线程的？

官方表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）。
但是，我们使用单线程的方式是无法发挥多核CPU 性能，不过我们可以通过在单机开多个Redis 实例来完善！

警告1：这里我们一直在强调的单线程，只是在处理我们的网络请求的时候只有一个线程来处理，一个正式的Redis Server运行的时候肯定是不止一个线程的，这里需要大家明确的注意一下！例如Redis进行持久化的时候会以子进程或者子线程的方式执行（具体是子线程还是子进程待读者深入研究）；

警告2：
从Redis 4.0版本开始会支持多线程的方式，但是，只是在某一些网络数据读写等操作上进行多线程的操作！

注意：CPU 是一个重要的影响因素，由于是单线程模型，Redis 更喜欢大缓存快速 CPU，而不是多核。

Redis的线程模型

问这个原理性的问题，可以结合着图来给面试官讲这个问题，边想图边讲最有说服力

redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：