Redis常见面试题

1.Redis  支持哪几种数据类型

String、List、Set、Sorted Set、hashes  bitmap  hyperloglog

2.Redis  有哪些适合的场景

会话缓存（Session Cache）

最常用的一种使用 Redis 的情景是会话缓存（session cache）。用 Redis 缓存会话比其他存

储（如 Memcached）的优势在于：Redis 提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？

幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用 Redis 来缓存会话的文

档。甚至广为人知的商业平台 Magento 也提供 Redis 的插件。

•  全页缓存（FPC）

除基本的会话 token 之外，Redis 还提供很简便的 FPC 平台。回到一致性问题，即使重启了Redis 实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似 PHP 本地 FPC。再次以 Magento 为例，Magento 提供一个插件来使用 Redis 作为全页缓存后端。此外，对 WordPress 的用户来说，Pantheon 有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。

•  队列

Reids 在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得 Redis 能作为一个

很好的消息队列平台来使用。Redis 作为队列使用的操作，就类似于本地程序语言（如

Python）对 list 的 push/pop 操作。

如果你快速的在 Google 中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用 Redis 创建非常好的后端工具，以满足各种队列需求。例如，Celery 有一个后台就是使用 Redis 作为 broker，你可以从这里去查看。

•  排行榜/计数器

Redis 在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合

（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis 只是正好提供了这

两种数据结构。所以，我们要从排序集合中获取到排名最靠前的 10 个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你

需要这样执行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games 就是一个很好的例子，用 Ruby 实现的，它的排行榜就是使用 Redis 来存储数据的，你可以在这里看到。

•  发布/订阅

最后（但肯定不是最不重要的）是 Redis 的发布/订阅功能。发布/订阅的使用场景确实非常

多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用

Redis 的发布/订阅功能来建立聊天系统！

活跃用户数统计

用户日活、月活、留存率等均可以用redis位数组来存储，还是以每天的日期作为key，用户活跃了就写入offset为用户id的位值1。

同理月活也是如此。

用户是否在线以及总在线人数统计

同样是使用一个位数组，用户的id映射偏移量，在线标识为1，下线标识为0。即可实现用户上下线查询和总在线人数的统计

APP内用户的全局消息提示小红点

现在大多数的APP里都有站内信的功能，当有消息的时候，则提示一个小红点，代表用户有新的消息。

点赞/取消点赞：

　　假设用户ID为100，对照片ID为100的照片进行点赞。首先根据照片ID生成数据存储的redis key，比如生成策略是like_photo:{photo_id}，用户ID为1000的用户点赞只需将like_photo:100的第1000位设置为1即可（取消置为0）。

redis setbit操作的时间复杂度为O（1），所以这种点赞方式十分高效。

当前是否点赞：

　　用户打开图片的时候需要查询当前是否点赞过该照片，查询是否点赞可以通过redis getbit操作实现。

查询点赞总次数：

　　比如需要显示照片ID为1000的照片的获赞总次数，只需对like_photo:1000进行位图计数操作即可：bitcount。时间复杂度为O(N)。个人以为可以在照片表中加一个字段记录获赞总次数，这样就不用循环统计各个照片的获赞次数。

redis还提供了bittop等其他一些API，可以实现一些有趣的事。

3.怎么理解 Redis  事务？

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

4.Redis  事务相关的命令有哪几个？

MULTI、EXEC、DISCARD、WATCH

 

 

5.Redis集群

首先下载linux版本的redis安装包，解压，找到redis的conf文件，配置端口号，配置要开启的数据库，看有几个库，然后再配置redis开启后日志存储的位置，数据的存储位置，支持后台运行模式，在配置下开启集群模式，完成之后，保存，复制几分，然后启动，多启动几台单台服务，一般都是一组一组，我们一般都配置六台，总共三组，所有单台服务启动完毕后，通过redis-trib(踹 bu).rb  create  --replicas(re pu li kai si)   1  127.0.0.1:7000 127.0.0.1:7001  127.0.0.1:7002 127.0.0.1:7003  127.0.0.1:7004  127.0.0.1:7005

Redis 集群

Redis 在3.0版本前只支持单实例模式，虽然支持主从模式、哨兵模式部署来解决单点故障

Redis 在 3.0 版本以后就推出了集群模式。

Redis 集群搭建规划，由于集群至少需要6个节点（3主3从模式）

我们计划集群中 Redis 节点的端口号为 9001-9006 ，端口号即集群下各实例文件夹。数据存放在 端口号/data 文件夹中。

2.复制执行脚本

在 /usr/local/redis-cluster 下创建 bin 文件夹，用来存放集群运行脚本，并把安装好的 Redis 的 src 路径下的运行脚本拷贝

3.复制一个新 Redis 实例

我们现在从已安装好的 Redis 中复制一个新的实例到 9001 文件夹，并修改 redis.conf 配置。修改 redis.conf 配置和单点唯一区别是下图部分，其余还是常规的这几项：

port 9001（每个节点的端口号）

daemonize yes bind 192.168.119.131（绑定当前机器 IP）

 dir /usr/local/redis-cluster/9001/data/（数据文件存放位置）

 pidfile /var/run/redis_9001.pid（pid 9001和port要对应）

cluster-enabled yes（启动集群模式）

cluster-config-file nodes9001.conf（9001和port要对应）

cluster-node-timeout 15000

appendonly yes

4. 再复制出五个新 Redis 实例

我们已经完成了一个节点了，其实接下来就是机械化的再完成另外五个节点，其实可以这么做：把 9001 实例 复制到另外五个文件夹中，唯一要修改的就是 redis.conf 中的所有和端口的相关的信息即可，其实就那么四个位置。开始操作，看图：

5. 调用 ruby 命令来进行创建集群，--replicas 1 表示主从复制比例为 1:1，即一个主节点对应一个从节点；然后，默认给我们分配好了每个主节点和对应从节点服务，以及 solt 的大小，因为在 Redis 集群中有且仅有 16383 个 solt ，默认情况会给我们平均分配，当然你可以指定，后续的增减节点也可以重新分配

6.redis持久化

redis是一个内存数据库，数据保存在内存中，但是我们都知道内存的数据变化是很快的，也容易发生丢失。幸好Redis还为我们提供了持久化的机制，分别是RDB(Redis DataBase)和AOF(Append Only File)。

持久化流程

既然redis的数据可以保存在磁盘上，那么这个流程是什么样的呢？

要有下面五个过程：

（1）客户端向服务端发送写操作(数据在客户端的内存中)。

（2）数据库服务端接收到写请求的数据(数据在服务端的内存中)。

（3）服务端调用write这个系统调用，将数据往磁盘上写(数据在系统内存的缓冲区中)。

（4）操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。

（5）磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)

RDB机制

既然RDB机制是通过把某个时刻的所有数据生成一个快照来保存，那么就应该有一种触发机制，是实现这个过程。对于RDB来说，提供了三种机制：save、bgsave、自动化。

RDB其实就是把数据以快照的形式保存在磁盘上。什么是快照呢，你可以理解成把当前时刻的数据拍成一张照片保存下来。

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

RDB 的优势和劣势

①、优势

（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。

（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

②、劣势

RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

AOF机制

全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

优点

（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。

（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

缺点

（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来

7.Redis 缓存穿透 + 缓存雪崩 + 缓存击穿的原因和解决方案

7.1缓存穿透

       缓存穿透是指查询一个根本不存在的数据，缓存层和持久层都不会命中。在日常工作中出于容错的考虑，如果从持久层查不到数据则不写入缓存层，缓存穿透将导致不存在的数据每次请求都要到持久层去查询，失去了缓存保护后端持久的意义

缓存穿透示意图：

 

缓存穿透问题可能会使后端存储负载加大，由于很多后端持久层不具备高并发性，甚至可能造成后端存储宕机。通常可以在程序中统计总调用数、缓存层命中数、如果同一个Key的缓存命中率很低，可能就是出现了缓存穿透问题。

       造成缓存穿透的基本原因有两个。第一，自身业务代码或者数据出现问题（例如：set 和 get 的key不一致），第二，一些恶意攻击、爬虫等造成大量空命中（爬取线上商城商品数据，超大循环递增商品的ID）

解决方案：

1. 缓存空对象

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

       缓存空对象会有两个问题：第一，value为null 不代表不占用内存空间，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象

2. 布隆过滤器拦截

        在访问缓存层和存储层之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截，当收到一个对key请求时先用布隆过滤器验证是key否存在，如果存在在进入缓存层、存储层。可以使用bitmap做布隆过滤器。这种方法适用于数据命中不高、数据相对固定、实时性低的应用场景，代码维护较为复杂，但是缓存空间占用少。

        布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

算法描述：

初始状态时，BloomFilter是一个长度为m的位数组，每一位都置为0。

添加元素x时，x使用k个hash函数得到k个hash值，对m取余，对应的bit位设置为1。

判断y是否属于这个集合，对y使用k个哈希函数得到k个哈希值，对m取余，所有对应的位置都是1，则认为y属于该集合（哈希冲突，可能存在误判），否则就认为y不属于该集合。可以通过增加哈希函数和增加二进制位数组的长度来降低错报率。

 

错报原因：

         一个key映射数组上多位，一位会被多个key使用，也就是多对多的关系。如果一个key映射的所有位值为1，就判断为存在。但是可能会出现key1 和  key2 同时映射到下标为100的位，key1不存在，key2存在，这种情况下会发生错误率

方案对比：

 

7.2缓存雪崩

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

解决方案：

可以把缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务。利用sentinel或cluster实现。

采用多级缓存，本地进程作为一级缓存，redis作为二级缓存，不同级别的缓存设置的超时时间不同，即使某级缓存过期了，也有其他级别缓存兜底

缓存的过期时间用随机值，尽量让不同的key的过期时间不同（例如：定时任务新建大批量key，设置的过期时间相同）

7.3缓存击穿

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂（意味着对数据库压力相对较大）的key突然失效了（可以理解为redis的缓存突然无了），无数的请求访问会在瞬间给数据库带来巨大的冲击。

当前key是一个热点key（例如一个秒杀活动），并发量非常大。

重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等。

在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。

分布式互斥锁

      只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。set(key,value,timeout)

 

2. 永不过期

• 从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。
• 从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去更新缓存

2种方案对比：

 

分布式互斥锁：这种方案思路比较简单，但是存在一定的隐患，如果在查询数据库  和 重建缓存（key失效后进行了大量的计算）时间过长，也可能会存在死锁和线程池阻塞的风险，高并发情景下吞吐量会大大降低！但是这种方法能够较好地降低后端存储负载，并在一致性上做得比较好。

“永远不过期”：这种方案由于没有设置真正的过期时间，实际上已经不存在热点key产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。

1. Mysql和Redis的双写一致性

8.1场景：

双写一致性指的是当我们更新了数据库的数据之后redis中的数据 也要同步去更新。使用redis读取数据的流程，当用户访问数据的时候，会先从缓存中读取数据，如果命中缓存的话，那么直接把缓存中的数据返回给用户，如果缓存中没有数据的话，先查询数据库把查询到的数据保存到缓存中，然后返回给用户。

8.2保证双写一致性的策略

1、先更新缓存，再更新数据库

2、先更新数据库，再更新缓存

3、先删除缓存，再更新数据库

4、先更新数据库，再删除缓存

8.3.四种策略的优缺点

1、先更新缓存，再更新数据库

问题很明显如果更新缓存成功，更新数据库失败，就会造成缓存的脏数据

2、先更新数据库，再更新缓存

如果再高并发的情况下，可能会存在如下的情况，线程A更新了数据库，如果由于网络或者其他的原因，线程A还没来得及更新缓存，这时候有一个线程B更新了数据库，更新了缓存，这时候线程A才更新缓存，这时候就会导致线程B对缓存的更新丢失了，像事务丢失的情况

3、先删除缓存，再更新数据库

这种策略可能已经避免掉了，策略2中缓存丢失的情况，但是再高并发的情况下，也会有不一致的情况，比如线程A做写操作，首先删除缓存然后准备更新数据库，这时候，线程B执行了写操作，没有命中缓存，然后查询数据库，这时候读取的是旧值，并把查询到的旧值保存到缓存中，接着线程A完成了数据库的更新，这时候数据库和缓存又出现了不一致的情况，解决方案：我们只要再线程A，完成数据库的更新之后，稍作延迟再删除一次缓存，也叫作延迟双删。这里的延迟时间一定要大于业务的一次读操作的时间。

4、先更新数据库，再删除缓存

再高并发的情况下，也会有不一致的情况，比如线程A做读取数据的操作，正准备写入缓存的时候，线程B更新了数据库，然后执行了删除缓存的操作，这时候线程A才把旧值写入到缓存中，虽然这种情况出现的概率比较低，因为写操作的时候要大于一次读操作的时间的。解决方案：延迟双删，延时双删还是有问题的，如果删除缓存失败怎么办，当然是再次删除，不断的循环删除。删除失败后我们可以将要删除的key放入到队列中，然后尝试重复删除，直到删除成功。

1. Redis有哪几种模式

9.1.主从模式

1.主从模式是最为简单的redis集群模式

2.主要工作模式是主从复制。主数据库可以执行读写功能，而从数据库只能执行读功能。主数据库数据发生变化，会自动同步到从数据库。

3.主数据库为master，从数据库为slave，一个master可以有多个slave，一个slave只能有一个master，slave挂了，重新启动会从master同步数据

master挂了，服务器只能进行读功能，不能执行写功能，直到master重新启动同步数据后，才能提供写服务。

9.2.哨兵模式

1.可以解决主从模式的弊端：master挂掉之后不能提供写功能。

2.哨兵模式是建立在主从模式的

3.当master挂掉之后，会自动从slave中选一个作为master。若master重新启动，master则会转化为现有的master下的一个slave

4.当slave切换时，会通过发布订阅方式，将slave所对应的master更改

5.因为哨兵也是一个进程，所以也有挂掉的可能，需要配置多个哨兵互相监督。一个哨兵可以监督多个主从数据库。同样，一个主从数据库可以被多个哨兵监督。

9.3.集群Cluster模式

1.redis cluster是Redis的分布式解决方案，在3.0版本推出后有效地解决了redis分布式方面的需求，自动将数据进行分片，每个master上放一部分数据提供内置的高可用支持，部分master不可用时，还是可以继续工作的

2.支撑N个redis master node，每个master node都可以挂载多个slave node

3.高可用，因为每个master都有salve节点，那么如果mater挂掉，redis cluster这套机制，就会自动将某个slave切换成master

1. 了解Redis 的回收策略（淘汰策略）吗？

Redis 5.0版本中约定了八种内存淘汰策略，在内存不足以容纳新写入数据时触发。关于已设置过期时间的数据集（server.db[i].expires），采用如下四种淘汰策略：

volatile-lru：淘汰最近最少使用的数据。不推荐

volatile-ttl：淘汰将要过期的数据。不推荐

volatile-random：随机淘汰数据。不推荐

volatile-lfu：淘汰使用频率最低的数据。

关于未设置过期时间的数据集（server.db[i].dict），采用如下三种淘汰策略：

allkeys-lru：淘汰最近最少使用的数据。推荐使用，目前项目在用这种。

allkeys-lfu：淘汰使用频率最低的数据。

allkeys-random：随机淘汰数据。应该也没人用吧，你不删最少使用Key，却随机删。

另外一种策略就是no-enviction（禁止驱逐策略）：当内存使用超过配置的阈值时会返回错误，不会驱逐任何键。意思是当内存不足以容纳新入数据时，新写入操作就会报错，查询请求可以继续进行，线上任务也不能持续进行，采用此策略可以保证数据不被丢失。redis淘汰数据时还会同步到aof，使用策略规则：

（1）如果数据访问频率呈现泊松分布，则使用 allkeys-lru

（2）如果数据访问频率呈现均匀分布，则使用allkeys-random。