Redis面试-高频常考30题（面试突击，建议收藏）

1.BigKey问题，多大算big?你如何发现?如何删除?如何处理?

关于bigkey的面试题，已经在博客
Redis7实战加面试题-高阶篇（Redis线程与IO多路复用，BigKey，缓存双写）
里详细说明

2.手机登录某App，短信验证码下发功能，请用redis实现并说说思路

面试回答：
业务场景

核心代码：

3.新浪微博或QQ，实现共同的好友功能，如果用redis你如何实现说说思路

面试回答：
业务场景：本质就是求两个对象的交集
核心代码：

4.Redis持久化是什么?RDB和AOF相关特性和工作原理你分别谈谈

持久化相关面试题，已经在博客
Redis7实战加面试题-基础篇（Redis持久化,Redis事务,Redis管道,Redis发布订阅）
里详细说明

5.Redis的事务是什么?怎么操作实现?它和传统的mysql数据库事务有什么不同

面试回答：
是什么：
官网：https://redis.io/docs/manual/transactions/
可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞。
工作原理：
本质就是一个队列中，一次性、顺序性、排他性的执行一系列Redis命令。通过3个步骤完成
1 开启：以MULTI开始一个事务
2 入队：将多个命令入队到事务中，接到这些命令并不会立即执行， 而是放到等待执行的事务队列里面
3 执行：由EXEC命令触发事务

Redis事务VS数据库事务：

6.Redis复制功能底层原理和工作流程是什么?

面试回答：
就是主从复制,master以写为主，Slave以读为主。当master数据变化的时候，自动将新的数据异步同步到其它slave数据库
复制原理和工作流程
1.slave启动，同步初请：
slave启动成功连接到master后会发送一个sync命令。slave首次全新连接master,一次完全同步（全量复制)将被自动执行，slave自身原有数据会被master数据覆盖清除
2.首次连接，全量复制：
master节点收到sync命令后会开始在后台保存快照(即RDB持久化，主从复制时会触发RDB)同时收集所有接收到的用于修改数据集命令缓存起来,master节点执行RDB持久化完后，master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步。
而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化
3.心跳持续，保持通信：
repl-ping-replica-period 10

4.进入平稳，增量复制：
Master继续将新的所有收集到的修改命令自动依次传给slave,完成同步
5.从机下线，重连续传：
master会检查backlog里面的offset,master和slave都会保存一个复制的offset还有一个masterId,offset是保存在backlog中的。Master只会把已经复制的offset后面的数据复制给Slave，类似断点续传

7.Redis哨兵功能你使用过吗?主观下线和客观下线你谈谈

Redis哨兵功能和原理已经在博客
Redis7实战加面试题-基础篇（Redis复制(replica)，Redis哨兵(sentinel)，Redis集群(cluster)）
详细说明，不再重复

8.Redis管道命令你怎么理解的?

面试回答：
pipeline出现的背景及是什么
Redis客户端执行一条命令分4个过程：发送命令－〉命令排队－〉命令执行－〉返回结果
这个过程称为Roundtriptime(简称RTT,往返时间)，Redis的原生批命令（mget和mset）有效节约了RTT，但大部分命令不支持批量操作，需要消耗N次RTT产生多次往返，比如set k1 v1,get k1,lpush key…一个命令来回一趟，徒增RTT。这个时候需要pipeline来解决这个问题。Pipeline是为了解决RTT往返回时，仅仅是将命令打包一次性发送，对整个Redis的执行不选成其它任何影响，是提升性能的利器。

9.Redis中的主要命令数据类似和使用场景，你谈谈

面试回答：

10.集群中slot槽位映射，会采用hash算法，你知道几种?你用哪—种

面试回答：
哈希取余分区：

—致性哈希算法分区：
一致性Hash算法背景：一致性哈希算法在1997年由麻省理工学院中提出的，设计目标是为了解决
分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数不OK了。
能干嘛：提出一致性Hash解决方案。目的是当服务器个数发生变动时，尽量减少影响客户端到服务器的映射关系
3大步骤：
算法构建一致性哈希环：

一致性哈希环
一致性哈希算法必然有个hash函数并按照算法产生hash值，这个算法的所有可能哈希值会构成一个全量集，这个集合可以成为一个hash空间[0,2^32-1]，这个是一个线性空间，但是在算法中，我们通过适当的逻辑控制将它首尾相连(0
= 2 ^32),这样让它逻辑上形成了一个环形空间。 它也是按照使用取模的方法，前面笔记介绍的节点取模法是对节点（服务器）的数量进行取模。而一致性Hash算法是对2 ^
32取模，简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0-2^
32-1（即哈希值是一个32位无符号整形），整个哈希环如下图：整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、……直到2^
32-1，也就是说0点左侧的第一个点代表2^ 32-1， 0和2^
32-1在零点中方向重合，我们把这个由2^32个点组成的圆环称为Hash环。

redis服务器IP节点映射

节点映射
将集群中各个IP节点映射到环上的某一个位置。将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置。假如4个节点NodeA、B、C、D，经过IP地址的哈希函数计算(hash(ip))，使用IP地址哈希后在环空间的位置如下：

key落到服务器的落键规则

当我们需要存储一个kv键值对时，首先计算key的hash值，hash(key)，将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上。如我们有Object
A、Object B、Object C、Object
D四个数据对象，经过哈希计算后，在环空间上的位置如下：根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node
B上，C被定为到Node C上，D被定为到Node D上。

优点：

—致性哈希算法的容错性

容错性 假设Node
C宕机，可以看到此时对象A、B、D不会受到影响。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。简单说，就是C挂了，受到影响的只是B、C之间的数据且这些数据会转移到D进行存储

一致性哈希算法的扩展性

扩展性
数据量增加了，需要增加一台节点NodeX，X的位置在A和B之间，那收到影响的也就是A到X之间的数据，重新把A到X的数据录入到X上即可，不会导致hash取余全部数据重新洗牌。

缺点:一致性哈希算法的数据倾斜问题

Hash环的数据倾斜问题
一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题，例如系统中只有两台服务器：

小总结：
为了在节点数目发生改变时尽可能少的迁移数据。将所有的存储节点排列在收尾相接的Hash环上，每个key在计算Hash后会顺时针找到临近的存储节点存放。而当有节点加入或退出时仅影响该节点在Hash环上顺时针相邻的后续节点。
优点
加入和删除节点只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响。
缺点
数据的分布和节点的位置有关，因为这些节点不是均匀的分布在哈希环上的，所以数据在进行存储时达不到均匀分布的效果。
哈希槽分区，通常采用
是什么：
1 为什么出现

哈希槽实质就是一个数组，数组[0,2^14 -1]形成hash slot空间。
2 能干什么：解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据。

槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配
3 多少个hash槽
一个集群只能有16384个槽，编号0-16383（0-2^14-1）。这些槽会分配给集群中的所有主节点，分配策略没有要求。集群会记录节点和槽的对应关系，解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取模，余数是几key就落入对应的槽里。HASH_SLOT = CRC16(key) mod 16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。
HASH_SLOT = CRC16(key) mod 16384
哈希槽计算：
Redis 集群中内置了 16384 个哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。当需要在 Redis 集群中放置一个 key-value时，redis先对key使用crc16算法算出一个结果然后用结果对16384求余数[ CRC16(key) % 16384]，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，也就是映射到某个节点上。如下代码，key之A 、B在Node2， key之C落在Node3上

11.为什么redis集群的最大槽数是16384个?

面试回答：
Redis集群并没有使用一致性hash而是引入了哈希槽的概念。Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。但为什么哈希槽的数量是16384（2^ 14）个呢？CRC16算法产生的hash值有16bit，该算法可以产生2^16=65536个值。
换句话说值是分布在0~65535之间，有更大的65536不用为什么只用16384就够？作者在做mod运算的时候，为什么不mod65536，而选择mod16384？ HASH_SLOT = CRC16(key) mod 65536为什么没启用

https://github.com/redis/redis/issues/2576

正常的心跳数据包带有节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置。
这意味着它们包含原始节点的插槽配置，该节点使用2k的空间和16k的插槽，但是会使用8k的空间（使用65k的插槽）。
同时，由于其他设计折衷，Redis集群不太可能扩展到1000个以上的主节点。
因此16k处于正确的范围内，以确保每个主机具有足够的插槽，最多可容纳1000个矩阵，但数量足够少，可以轻松地将插槽配置作为原始位图传播。请注意，在小型群集中，位图将难以压缩，因为当N较小时，位图将设置的slot / N位占设置位的很大百分比。

(1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为65536时，这块的大小是: 65536÷8÷1024=8kb
在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。 当槽位为16384时，这块的大小是: 16384÷8÷1024=2kb
因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。
(2)redis的集群主节点数量基本不可能超过1000个。
集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者不建议redis cluster节点数量超过1000个。 那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。
(3)槽位越小，节点少的情况下，压缩比高，容易传输
Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。 如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。
计算结论：

12.你们公司怎么保证redis和mysql的双写一致性，更新策略你说说

关于双写一致性的4种策略，已经在博客
Redis7实战加面试题-高阶篇（Redis线程与IO多路复用，BigKey，缓存双写）
详细说明

13.某淘网站首页，请统计每天的点击率是多少?要求支持亿级UV的统计方案

关于这一面试题的答案，在博客Redis7实战加面试题-高阶篇（案例落地实战bitmap/hyperloglog/GEO）
已详细说明

14.某团附近的酒店、附近的单车，类似附近的XXX功能如何实现

这一问题的答案，已经在博客
Redis7实战加面试题-高阶篇（案例落地实战bitmap/hyperloglog/GEO）
已详细说明

15.请简述布隆过滤器BloomFilter原理和使用场景

关于布隆过滤器相关知识点和面试题目，已在博客
Redis7实战加面试题-高阶篇（布隆过滤器BloomFilter，缓存预热+缓存雪崩＋缓存击穿+缓存穿透）
详细说明

16.缓存雪崩是什么，如何避免

关于缓存相关内容和面试题，已在博客
Redis7实战加面试题-高阶篇（布隆过滤器BloomFilter，缓存预热+缓存雪崩＋缓存击穿+缓存穿透）
详细说明

17.缓存击穿是什么，有哪些危害?如何避免

关于缓存相关内容和面试题，已在博客
Redis7实战加面试题-高阶篇（布隆过滤器BloomFilter，缓存预热+缓存雪崩＋缓存击穿+缓存穿透）
详细说明

18.缓存穿透是什么，如何避免

答案同样在上述博客。

19.缓存在使用中，你们公司有编码或配置规范?

面试回答：
1.规范部署、规范目录、自制脚本，搭建一个稳定的Redis环境
2.主从模式下、cluster模式下中主从节点一定要分机器部署，防单点故障
3.一定要同网部署，同交换机为最佳，时间<2ms，否则意义不大
4.单个节点内存不宜过多，太大会影响性能，如果数据量多，建议从业务上进行拆分，一般经验值不超过10G
5.Redis的值对象不宜过大，1K级别为最好，超过10K时，要特别小心，可能会影响性能问题
6.虽然万物皆可为String，但若操作对象存在复杂结构时，优先考虑Hash，List等其它类型
7.在无强烈持久化需求时，建议不要开启AOF机制
8.无论Redis如何演进，目前缓存仍然作为Redis最多、最稳定的使用场景
9.一定要防止Key集中过期，防止给业务带来较大波大
10.建议线上采用普通密码认证方式或者ACL机制，不建议无密码、TLS机制
11.上线前做好基准测试，预估一下Redis性能数据

20.请谈谈实现一个Redis分布式锁要达到哪些要求和条件

面试回答：
一个靠谱分布式锁需要具备的条件和刚需
独占性：OnlyOne，任何时刻只能有且仅有一个线程持有
高可用：若redis集群环境下，不能因为某一个节点挂了而出现获取锁和释放锁失败的情况。高并发请求下，依旧性能OK好使
防死锁：杜绝死锁，必须有超时控制机制或者撤销操作，有个兜底终止跳出方案
不乱抢：防止张冠李戴，不能私下unlock别人的锁，只能自己加锁自己释放，自己约的锁含着泪也要自己解
重入性：同一个节点的同一个线程如果获得锁之后，它也可以再次获取这个锁。

21.手写Redis分布式锁思路和步骤请你谈谈

通常开发中，秒杀下单、抢红包等等业务场景，都需要用到分布式锁。而Redis非常适合作为分布式锁使用。
技术难点：
1、获取锁和释放锁的性能要好
2、锁必须是原子性的，否则可能导致多个请求都获取到锁
3、预防死锁的发生
分布式方案案例：
1、Redis分布式锁方案一：SETNX+EXPIRE (项目中一般不用，仅供学习)
2、Redis分布式锁方案二：while判断并自旋重试获取锁+hset含自然过期时间+Lock接口规范+Lua脚本删除锁命令
3、Redis分布式锁方案三：采用Redisson框架实现，Redisson框架实现的锁非常丰富，底层也是采用Redis实现，框架内实现了可重入锁、读写锁、信号量锁、闭锁、红锁等。

22.Redis分布式锁如何续期? watchDog看门狗什么意思

确保redisLock过期时间大于业务执行时间的问题，自动续期问题，俗称看门狗。单我们加锁成功拿到redis分布式锁后，同时也异步启动一个线程，这个就是看门狗线程，它会判断对应key是否到过期时间的1/3，如果到了，自动执行expire key命令，对key进行续期，知道任务完成。比如过期时间是30秒，到第20秒后，会自动给key续命加到30秒，以此类推。当然，实现看门狗的任务通过lua脚本来完成

//==============自动续期
if redis.call('HEXISTS',KEYS[1],ARGV[1]) == 1 then
  return redis.call('expire',KEYS[1],ARGV[2])
else
  return 0
end

23.Redis分布式锁之RedLock红锁算法你了解吗

面试回答：
Redis分布式锁-Redlock红锁算法Distributed locks with Redis
官网：https://redis.io/docs/manual/patterns/distributed-locks/

为什么学习这个?怎么产生的?

线程 1 首先获取锁成功，将键值对写入 redis 的 master 节点，在 redis 将该键值对同步到 slave
节点之前，master 发生了故障；redis 触发故障转移，其中一个 slave 升级为新的
master，此时新上位的master并不包含线程1写入的键值对，因此线程 2
尝试获取锁也可以成功拿到锁，此时相当于有两个线程获取到了锁，可能会导致各种预期之外的情况发生，例如最常见的脏数据。
我们加的是排它独占锁，同一时间只能有一个建redis锁成功并持有锁，严禁出现2个以上的请求线程拿到锁。危险的

Redlock算法设计理念
redis之父提出了Redlock算法解决这个问题
Redis也提供了Redlock算法，用来实现基于多个实例的分布式锁。锁变量由多个实例维护，即使有实例发生了故障，锁变量仍然是存在的，客户端还是可以完成锁操作。Redlock算法是实现高可靠分布式锁的一种有效解决方案，可以在实际开发中使用。

设计理念：

该方案也是基于（set 加锁、Lua 脚本解锁）进行改良的，所以redis之父antirez 只描述了差异的地方，大致方案如下。
假设我们有N个Redis主节点，例如 N = 5这些节点是完全独立的，我们不使用复制或任何其他隐式协调系统，为了取到锁客户端执行以下操作：

该方案为了解决数据不一致的问题，直接舍弃了异步复制只使用 master 节点，同时由于舍弃了 slave，为了保证可用性，引入了 N 个节点，官方建议是 5。演示用3台实例来做说明。客户端只有在满足下面的这两个条件时，才能认为是加锁成功。条件1：客户端从超过半数（大于等于N/2+1）的Redis实例上成功获取到了锁；条件2：客户端获取锁的总耗时没有超过锁的有效时间。

解决方案

为什么是奇数？ N = 2X + 1 (N是最终部署机器数，X是容错机器数)
1 先知道什么是容错
失败了多少个机器实例后我还是可以容忍的，所谓的容忍就是数据一致性还是可以Ok的，CP数据一致性还是可以满足
加入在集群环境中，redis失败1台，可接受。2X+1 = 2 * 1+1 =3，部署3台，死了1个剩下2个可以正常工作，那就部署3台。
加入在集群环境中，redis失败2台，可接受。2X+1 = 2 * 2+1 =5，部署5台，死了2个剩下3个可以正常工作，那就部署5台。
2 为什么是奇数？
最少的机器，最多的产出效果
加入在集群环境中，redis失败1台，可接受。2N+2= 2 * 1+2 =4，部署4台
加入在集群环境中，redis失败2台，可接受。2N+2 = 2 * 2+2 =6，部署6台

天上飞的理念(RedLock)必然有落地的实现(Redisson)：
Redisson是java的redis客户端之一，提供了一些api方便操作redis。
redisson之官网：https://redisson.org/
redisson之Github：https://github.com/redisson/redisson/wiki/%E7%9B%AE%E5%BD%95
redisson之解决分布式锁：https://github.com/redisson/redisson/wiki/8.-Distributed-locks-and-synchronizers

24.Redisson实现分布式锁和底层原理

Redisson源码解析部分面试题，已经在博客
Redis7实战加面试题-高阶篇（Redlock算法和底层源码分析）

25.Redis的缓存过期淘汰策略有哪些?你用哪—种

相关面试题已经在上述博客里详细记载

26.Redis源码读过吗?请说一下RedisObject对象

面试回答：
是什么：Redis内部所有存储的数据都使用redisObject来封装
redisobjec结构的作用：
为了便于操作，Redis采用redisObjec结构来统一五种不同的数据类型，这样所有的数据类型就都可以以相同的形式在函数间传递而不用使用特定的类型结构。同时，为了识别不同的数据类型，redisObjec中定义了type和encoding字段对不同的数据类型加以区别。简单地说，redisObjec就是string、hash、list、set、zset的父类，可以在函数间传递时隐藏具体的类型信息，所以作者抽象了redisObjec结构来到达同样的目的。

RedisObject各字段的含义：

1 4位的type表示具体的数据类型
2 4位的encoding表示该类型的物理编码方式见下表，同一种数据类型可能有不同的编码方式。
(比如String就提供了3种:int embstr raw)

3 lru字段表示当内存超限时采用LRU算法清除内存中的对象。
4 refcount表示对象的引用计数。
5 ptr指针指向真正的底层数据结构的指针。
案例：

27.Redis常用的String类型，为什么重新设计一个SDS数据结构?

面试回答：
C语言中字符串的展现

SDS管单动态字符串：
sds.h源码分析

Redis中字符串的实现,SDS有多种结构（sds.h）：
sdshdr5、(2^5=32byte)
sdshdr8、(2 ^ 8=256byte)
sdshdr16、(2 ^ 16=65536byte=64KB)
sdshdr32、 (2 ^ 32byte=4GB)
sdshdr64，2的64次方byte＝17179869184G用于存储不同的长度的字符串。

len 表示 SDS 的长度，使我们在获取字符串长度的时候可以在 O(1)情况下拿到，而不是像 C 那样需要遍历一遍字符串。

alloc 可以用来计算 free 就是字符串已经分配的未使用的空间，有了这个值就可以引入预分配空间的算法了，而不用去考虑内存分配的问题。

buf 表示字符串数组，真存数据的。

https://github.com/antirez/sds
Redis为什么重新设计一个SDS数据结构?

28.跳表你了解吗

面试回答：
是什么：
跳表是可以实现二分查找的有序链表
skiplist是一种以空间换取时间的结构。由于链表，无法进行二分查找，因此借鉴数据库索引的思想，提取出链表中关键节点（索引），先在关键节点上查找，再进入下层链表查找，提取多层关键节点，就形成了跳跃表， skiplist采用了多级索引，末端采用原始单链表进行存储
but
由于索引也要占据一定空间的，所以，索引添加的越多，空间占用的越多

总结来讲跳表=链表＋多级索引
为什么引出跳表
先从一个单链表来讲：
对于一个单链表来讲，即便链表中存储的数据是有序的，如果我们要想在其中查找某个数据，也只能从头到尾遍历链表。这样查找效率就会很低，时间复杂度会很高O(N)。

痛点：

解决方法：升维，也叫空间换时间。
优化：

从这个例子里，我们看出，加来一层索引之后，查找一个结点需要遍历的结点个数减少了，也就是说查找效率提高了。
优化2：画了一个包含64个结点的链表，按照前面讲的这种思路，建立了五级索引

跳表时间+空间复杂度介绍
跳表的时间复杂度（时间复杂度是O(logN)）

跳表的空间复杂度（空间复杂度是O(N)）

29.Redis单线程如何处理那么多并发客户端连接，为什么单线程还这么快

结论：

30.IO多路复用是什么，它是redis的底层实现，请你谈谈

关于多路复用的面试题，已经在博客Redis7实战加面试题-高阶篇（Redis为什么快?高性能设计之epoll和IO多路复用深度解析）

中详细说明