【收藏系列】这36道2021年常见Redis面试题，看了不恰亏~

一、什么是Redis？简述它的优缺点？

Redis的全称是：Remote Dictionary.Server，本质上是一个Key-Value类型的内存数据库，很像 memcached，整个数据库通通加载在内存当中进行操做，按期经过异步操做把数据库数据flush到硬盘 上进行保存。 由于是纯内存操做，Redis的性能很是出色，每秒能够处理超过 10万次读写操做，是已知性能最快的 Key-Value DB。 Redis的出色之处不只仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限 制是1GB，不像 memcached只能保存1MB的数据，所以Redis能够用来实现不少有用的功能。 比方说用他的List来作FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set能够作高 性能的tag系统等等。 另外Redis也能够对存入的Key-Value设置expire时间，所以也能够被看成一 个功能增强版的 memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制，不能用做海量数据的高性能 读写，所以Redis适合的场景主要局限在较小数据量的高性能操做和运算上。

二、Redis与memcached相比有哪些优点？ 1.memcached全部的值均是简单的字符串，redis做为其替代者，支持更为丰富的数据类型 2.redis的速度比memcached快不少redis的速度比memcached快不少 3.redis能够持久化其数据redis能够持久化其数据 三、Redis支持哪几种数据类型？ String、List、Set、Sorted Set、hashes

四、Redis主要消耗什么物理资源？ 内存。

五、Redis有哪几种数据淘汰策略？ 1.noeviction:返回错误当内存限制达到，而且客户端尝试执行会让更多内存被使用的命令。 2.allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。 3.volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过时集合的键,使得新添加的数据有空间存 放。 4.allkeys-random: 回收随机的键使得新添加的数据有空间存放。 5.volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过时集合的键。 6.volatile-ttl: 回收在过时集合的键，而且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间 存放。

六、Redis官方为何不提供Windows版本？ 由于目前Linux版本已经至关稳定，并且用户量很大，无需开发windows版本，反而会带来兼容性等问 题。

七、一个字符串类型的值能存储最大容量是多少？ 512M

八、为何Redis须要把全部数据放到内存中？ Redis为了达到最快的读写速度将数据都读到内存中，并经过异步的方式将数据写入磁盘。 因此redis具备快速和数据持久化的特征，若是不将数据放在内存中，磁盘I/O速度为严重影响redis的 性能。 在内存愈来愈便宜的今天，redis将会愈来愈受欢迎， 若是设置了最大使用的内存，则数据已有记录数达 到内存限值后不能继续插入新值。

九、Redis集群方案应该怎么作？都有哪些方案？

1.codis

2.目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在节点数量改变状况下，旧节点 数据可恢复到新hash节点。 redis cluster3.0自带的集群，特色在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自 身支持节点设置从节点。具体看官方文档介绍。 3.在业务代码层实现，起几个毫无关联的redis实例，在代码层，对key进行hash计算，而后去对应的 redis实例操做数据。这种方式对hash层代码要求比较高，考虑部分包括，节点失效后的替代算法方 案，数据震荡后的自动脚本恢复，实例的监控，等等。 欢迎工做一到五年的Java工程师朋友们加入Java进阶架构学习交流：952124565，群内提供免费的 Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码， MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资 料）合理利用本身每一分每一秒的时间来学习提高本身，不要再用"没有时间“来掩饰本身思想上的懒 惰！趁年轻，使劲拼，给将来的本身一个交代！

十、Redis集群方案什么状况下会致使整个集群不可用？ 有A，B，C三个节点的集群,在没有复制模型的状况下,若是节点B失败了，那么整个集群就会觉得缺乏 5501-11000这个范围的槽而不可用。

十一、MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据？ redis内存数据集大小上升到必定大小的时候，就会施行数据淘汰策略。 其实面试除了考察Redis，很多公司都很重视高并发高可用的技术，特别是一线互联网公司，分布式、 JVM、spring源码分析、微服务等知识点已经是面试的必考题。

十二、Redis有哪些适合的场景？

（1）会话缓存（Session Cache） 最经常使用的一种使用Redis的情景是会话缓存（sessioncache），用Redis缓存会话比其余存储（如 Memcached）的优点在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，若是用户的 购物车信息所有丢失，大部分人都会不高兴的，如今，他们还会这样吗？ 幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为 人知的商业平台Magento也提供Redis的插件。 （

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

（3）队列 Reids在内存存储引擎领域的一大优势是提供list和set操做，这使得Redis能做为一个很好的消息队列 平台来使用。Redis做为队列使用的操做，就相似于本地程序语言（如Python）对 list 的 push/pop 操做。 若是你快速的在Google中搜索“Redis queues”，你立刻就能找到大量的开源项目，这些项目的目的 就是利用Redis建立很是好的后端工具，以知足各类队列需求。例如，Celery有一个后台就是使用 Redis做为broker，你能够从这里去查看。

（4）排行榜/计数器 Redis在内存中对数字进行递增或递减的操做实现的很是好。集合（Set）和有序集合（SortedSet）也使 得咱们在执行这些操做的时候变的很是简单，Redis只是正好提供了这两种数据结构。 因此，咱们要从排序集合中获取到排名最靠前的10个用户–咱们称之为“user_scores”，咱们只须要像 下面同样执行便可： 固然，这是假定你是根据你用户的分数作递增的排序。若是你想返回用户及用户的分数，你须要这样执 行： ZRANGE user_scores 0 10 WITHSCORES Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可 以在这里看到。 （5）发布/订阅 最后（但确定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实很是多。我已看见 人们在社交网络链接中使用，还可做为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建 立聊天系统！

1三、Redis支持的Java客户端都有哪些？官方推荐用哪一个？ Redisson、Jedis、lettuce等等，官方推荐使用Redisson。

1四、Redis和Redisson有什么关系？ Redisson是一个高级的分布式协调Redis客服端，能帮助用户在分布式环境中轻松实现一些Java的对 象 (Bloom filter, BitSet, Set, SetMultimap, ScoredSortedSet, SortedSet, Map, ConcurrentMap, List, ListMultimap, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock, AtomicLong, CountDownLatch, Publish / Subscribe, HyperLogLog)。

1五、Jedis与Redisson对比有什么优缺点？ Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持； Redisson实现了分布式和可扩展的Java数据结构，和Jedis相比，功能较为简单，不支持字符串操做， 不支持排序、事务、管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离，从 而让使用者可以将精力更集中地放在处理业务逻辑上。

1六、说说Redis哈希槽的概念？ Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每一个key通 过CRC16校验后对16384取模来决定放置哪一个槽，集群的每一个节点负责一部分hash槽。

1七、Redis集群的主从复制模型是怎样的？ 为了使在部分节点失败或者大部分节点没法通讯的状况下集群仍然可用，因此集群使用了主从复制模型, 每一个节点都会有N-1个复制品.

1八、Redis集群会有写操做丢失吗？为何？ Redis并不能保证数据的强一致性，这意味着在实际中集群在特定的条件下可能会丢失写操做。

1九、Redis集群之间是如何复制的？ 异步复制

20、Redis集群最大节点个数是多少？ 16384个

2一、Redis集群如何选择数据库？ Redis集群目前没法作数据库选择，默认在0数据库。

2二、Redis中的管道有什么用？ 一次请求/响应服务器能实现处理新的请求即便旧的请求还未被响应，这样就能够将多个命令发送到服务 器，而不用等待回复，最后在一个步骤中读取该答复。 这就是管道（pipelining），是一种几十年来普遍使用的技术。例如许多POP3协议已经实现支持这个功 能，大大加快了从服务器下载新邮件的过程。

2三、怎么理解Redis事务？ 事务是一个单独的隔离操做：事务中的全部命令都会序列化、按顺序地执行，事务在执行的过程当中，不会 被其余客户端发送来的命令请求所打断。 事务是一个原子操做：事务中的命令要么所有被执行，要么所有都不执行。

2四、Redis事务相关的命令有哪几个？ MULTI、EXEC、DISCARD、WATCH

2五、Redis key的过时时间和永久有效分别怎么设置？ EXPIRE和PERSIST命令

2六、Redis如何作内存优化？ 尽量使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存很是小，因此你应该 尽量的将你的数据模型抽象到一个散列表里面。 好比你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是 应该把这个用户的全部信息存储到一张散列表里面。

2七、Redis回收进程如何工做的？ 一个客户端运行了新的命令，添加了新的数据。 Redi检查内存使用状况，若是大于maxmemory的限制, 则根据设定好的策略进行回收。 一个新的命令被执行，等等。 因此咱们不断地穿越内存限制的边界，经过不断达到边界而后不断地回收回到边界如下。 若是一个命令的结果致使大量内存被使用（例如很大的集合的交集保存到一个新的键），不用多久内存限 制就会被这个内存使用量超越。

28.加锁机制

我们来看上面那张图，如今某个客户端要加锁。若是该客户端面对的是一个 redis cluster 集 群，他首先会根据 hash 节点选择一台机器。这里注意，仅仅只是选择一台机器！这点很关 键！紧接着，就会发送一段 lua 脚本到 redis 上，那段 lua 脚本以下所示：

为啥要用 lua 脚本呢？由于一大坨复杂的业务逻辑，能够经过封装在 lua 脚本中发送给 redis， 保证这段复杂业务逻辑执行的原子性。

那么，这段 lua 脚本是什么意思呢？这里 KEYS[1]表明的是你加锁的那个 key，好比说：RLoc k lock = redisson.getLock("myLock");这里你本身设置了加锁的那个锁 key 就是“myLock”。

ARGV[1]表明的就是锁 key 的默认生存时间，默认 30 秒。ARGV[2]表明的是加锁的客户端的 I D，相似于下面这样：8743c9c0-0795-4907-87fd-6c719a6b4586:1

给你们解释一下，第一段 if 判断语句，就是用“exists myLock”命令判断一下，若是你要加锁 的那个锁 key 不存在的话，你就进行加锁。如何加锁呢？很简单，用下面的命令：hset myLoc k

8743c9c0-0795-4907-87fd-6c719a6b4586:1 1，经过这个命令设置一个 hash 数据结构，这行 命令执行后，会出现一个相似下面的数据结构：

上述就表明“8743c9c0-0795-4907-87fd-6c719a6b4586:1”这个客户端对“myLock”这个锁 key 完 成了加锁。接着会执行“pexpire myLock 30000”命令，设置 myLock 这个锁 key 的生存时间 是 30 秒。好了，到此为止，ok，加锁完成了。

29.锁互斥机制

那么在这个时候，若是客户端 2 来尝试加锁，执行了一样的一段 lua 脚本，会咋样呢？很简 单，第一个 if 判断会执行“exists myLock”，发现 myLock 这个锁 key 已经存在了。接着第二 个 if 判断，判断一下，myLock 锁 key 的 hash 数据结构中，是否包含客户端 2 的 ID，可是明 显不是的，由于那里包含的是客户端 1 的 ID。

因此，客户端 2 会获取到 pttl myLock 返回的一个数字，这个数字表明了 myLock 这个锁 key 的剩余生存时间。好比还剩 15000 毫秒的生存时间。此时客户端 2 会进入一个 while 循环，不 停的尝试加锁。

30.watch dog 自动延期机制

客户端 1 加锁的锁 key 默认生存时间才 30 秒，若是超过了 30 秒，客户端 1 还想一直持有这把 锁，怎么办呢？

简单！只要客户端 1 一旦加锁成功，就会启动一个 watch dog 看门狗，他是一个后台线程，会 每隔 10 秒检查一下，若是客户端 1 还持有锁 key，那么就会不断的延长锁 key 的生存时间。

31.可重入加锁机制

那若是客户端 1 都已经持有了这把锁了，结果可重入的加锁会怎么样呢？好比下面这种代码：

这时咱们来分析一下上面那段 lua 脚本。第一个 if 判断确定不成立，“exists myLock”会显示锁 key 已经存在了。第二个 if 判断会成立，由于 myLock 的 hash 数据结构中包含的那个 ID，就 是客户端 1 的那个 ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”

此时就会执行可重入加锁的逻辑，他会用：

incrby myLock 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1 ，经过这个命令，对客户端 1 的加锁次数，累加 1。此时 myLock 数据结构变为下面这样：

你们看到了吧，那个 myLock 的 hash 数据结构中的那个客户端 ID，就对应着加锁的次数

32.释放锁机制

若是执行 lock.unlock()，就能够释放分布式锁，此时的业务逻辑也是很是简单的。其实说白 了，就是每次都对 myLock 数据结构中的那个加锁次数减 1。若是发现加锁次数是 0 了，说明 这个客户端已经再也不持有锁了，此时就会用：“del myLock”命令，从 redis 里删除这个 key。 而后呢，另外的客户端 2 就能够尝试完成加锁了。这就是所谓的分布式锁的开源 Redisson 框 架的实现机制。

通常咱们在生产系统中，能够用 Redisson 框架提供的这个类库来基于 redis 进行分布式锁的加 锁与释放锁。

33.上述 Redis 分布式锁的缺点

其实上面那种方案最大的问题，就是若是你对某个 redis master 实例，写入了 myLock 这种锁 key 的 value，此时会异步复制给对应的 master slave 实例。可是这个过程当中一旦发生 redis m aster 宕机，主备切换，redis slave 变为了 redis master。

接着就会致使，客户端 2 来尝试加锁的时候，在新的 redis master 上完成了加锁，而客户端 1 也觉得本身成功加了锁。此时就会致使多个客户端对一个分布式锁完成了加锁。这时系统在业 务语义上必定会出现问题，致使各类脏数据的产生。

因此这个就是 redis cluster，或者是 redis master-slave 架构的主从异步复制致使的 redis 分布 式锁的最大缺陷：在 redis master 实例宕机的时候，可能致使多个客户端同时完成加锁。

34.使用过Redis分布式锁么，它是怎么实现的？

先拿setnx来争抢锁，抢到以后，再用expire给锁加一个过时时间防止锁忘记了释放。 若是在setnx以后执行expire以前进程意外crash或者要重启维护了，那会怎么样？ set指令有很是复杂的参数，这个应该是能够同时把setnx和expire合成一条指令来用的！

35.使用过Redis作异步队列么，你是怎么用的？有什么缺点？

通常使用list结构做为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep 一会再重试。 缺点： 在消费者下线的状况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。 能不能生产一次消费屡次呢？ 使用pub/sub主题订阅者模式，能够实现1:N的消息队列。

36.什么是缓存穿透？如何避免？什么是缓存雪崩？何如避免？

缓存穿透 通常的缓存系统，都是按照key去缓存查询，若是不存在对应的value，就应该去后端系统查找（好比 DB）。一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统形成很大的压力。这就叫 作缓存穿透。 如何避免？

1：对查询结果为空的状况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了以后清理 缓存。

2：对必定不存在的key进行过滤。能够把全部的可能存在的key放到一个大的Bitmap中，查询时经过 该bitmap过滤。 缓存雪崩 当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压 力。致使系统崩溃。 如何避免？

1：在缓存失效后，经过加锁或者队列来控制读数据库写缓存的线程数量。好比对某个key只容许一个线 程查询数据和写缓存，其余线程等待。

2：作二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，能够访问A2，A1缓存失效时间设置为 短时间，A2设置为长期

3：不一样的key，设置不一样的过时时间，让缓存失效的时间点尽可能均匀。

最近看了一本Redis实战解析PDF，以为还不错，须要能够关注公众号【有故事的程序员】获取~