Redis面试题

一、redis的数据类型

1.1、STRING

1.2、HASH

1.3、LIST

1.4、SET

1.5、sorted SET

以redis为例，之所以流行是因为复杂数据结构的支持。对于List、Set、SortedSet、Hash这类结构，它的核心在于 在存储上提供简单运算 和 针对obj的结构化存储。再说白了，原来NoSQL的KV结构，对于用户来讲，接口就是一个remote的HashMap；仅有HashMap是不够的，用户还需要Set，还需要List等；实质上，是为用户提供 remote structure支持，解决用户的共享特性。另外用户还需要特殊的实现，如一些简单的事务性语义，一些难于实现的统计算法。更直接简单的数据结构等。

二、redis的为什么快

2.1、内存（储存）

存内存操作

2.2、单线程（计算）

避免了线程的切换

2.3、数据结构的优化（数据）

C语言实现，优化过的数据结构，基于几种基础的数据结构，redis做了大量的优化，性能极高

2.4、IO的多路复用（网络）

基于非阻塞的IO多路复用机制

三、6.0后为什么改成多线程

redis使用多线程并非是完全摒弃单线程，redis还是使用单线程模型来处理客户端的请求，只是使用多线程来处理数据的读写和协议解析，执行命令还是使用单线程。

这样做的目的是因为redis的性能瓶颈在于网络IO而非CPU，使用多线程能提升IO读写的效率，从而整体提高redis的性能。

四、热key问题怎么解决？

问题：

所谓热key问题就是，突然有几十万的请求去访问redis上的某个特定key，那么这样会造成流量过于集中，达到物理网卡上限，从而导致这台redis的服务器宕机引发雪崩。

针对热key的解决方案：

1、提前把热key打散到不同的服务器，降低压力

2、加入二级缓存，提前加载热key数据到内存中，如果redis宕机，走内存查询

五、什么是缓存击穿、缓存穿透、缓存雪崩？

5.1、缓存击穿

缓存击穿的概念就是单个key并发访问过高，过期时导致所有请求直接打到db上，这个和热key的问题比较类似，只是说的点在于过期导致请求全部打到DB上而已。

解决方案：

1、加锁更新，比如请求查询A，发现缓存中没有，对A这个key加锁，同时去数据库查询数据，写入缓存，再返回给用户，这样后面的请求就可以从缓存中拿到数据了。

2、将过期时间组合写在value中，通过异步的方式不断的刷新过期时间，防止此类现象。

5.2、缓存击穿

缓存穿透是指查询不存在缓存中的数据，每次请求都会打到DB，就像缓存不存在一样。

针对这个问题，加一层布隆过滤器。布隆过滤器的原理是在你存入数据的时候，会通过散列函数将它映射为一个位数组中的K个点，同时把他们置为1。

这样当用户再次来查询A，而A在布隆过滤器值为0，直接返回，就不会产生击穿请求打到DB了。

显然，使用布隆过滤器之后会有一个问题就是误判，因为它本身是一个数组，可能会有多个值落到同一个位置，那么理论上来说只要我们的数组长度够长，误判的概率就会越低，这种问题就根据实际情况来就好了。

5.3、缓存雪崩

多个缓存的key，集体实效，查询数据库

针对雪崩几个解决方案：

1、针对不同key设置不同的过期时间，避免同时过期

2、限流，如果redis宕机，可以限流，避免同时刻大量请求打崩DB

3、二级缓存，同热key的方案。

六、Redis的过期策略有哪些？

6.1、惰性删除

在查询的时候，如果发现过期了，则删除该数据

问题是，如果没有没有查询，则数据一致存在

6.2、定期清理

每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。

6.3、定时过期

每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

七、内存淘汰机制

7.1、已设置过期时间

1、volatile-lru：从已设置过期时间的key中，移除最近最少使用的key进行淘汰

2、volatile-ttl：从已设置过期时间的key中，移除将要过期的key

3、volatile-random：从已设置过期时间的key中随机选择key淘汰

7.2、全局处理

4、allkeys-lru：从key中选择最近最少使用的进行淘汰

5、allkeys-random：从key中随机选择key进行淘汰

6、noeviction：当内存达到阈值的时候，新写入操作报错

Redis的内存淘汰策略的选取并不会影响过期的key的处理。内存淘汰策略用于处理内存不足时的需要申请额外空间的数据；过期策略用于处理过期的缓存数据。

八、持久化

8.1、AOF

增量、操作过程指令、数据量大、恢复慢

AOF和RDB不同，AOF是通过保存redis服务器所执行的写命令来记录数据库状态的。

AOF通过追加、写入、同步三个步骤来实现持久化机制。

1、当AOF持久化处于激活状态，服务器执行完写命令之后，写命令将会被追加append到aof_buf缓冲区的末尾

2、在服务器每结束一个事件循环之前，将会调用flushAppendOnlyFile函数决定是否要将aof_buf的内容保存到AOF文件中，可以通过配置appendfsync来决定。

always ##aof_buf内容写入并同步到AOF文件
everysec ##将aof_buf中内容写入到AOF文件，如果上次同步AOF文件时间距离现在超过1秒，则再次对AOF文件进行同步
no ##将aof_buf内容写入AOF文件，但是并不对AOF文件进行同步，同步时间由操作系统决定

如果不设置，默认选项将会是everysec，因为always来说虽然最安全（只会丢失一次事件循环的写命令），但是性能较差，而everysec模式只不过会可能丢失1秒钟的数据，而no模式的效率和everysec相仿，但是会丢失上次同步AOF文件之后的所有写命令数据。

8.2、RDB

它的作用是将某个时间点上的数据库状态保存到RDB文件中

全量、状态数据、数据量小、恢复快；耗费性能

九、怎么实现Redis的高可用？

9.1、数据高可用

1、持久化

2、多份数据容灾隔离

主从架构

主从模式是最简单的实现高可用的方案，核心就是主从同步。主从同步的原理如下：

1、slave发送sync命令到master

2、master收到sync之后，执行bgsave，生成RDB全量文件

3、master把slave的写命令记录到缓存

4、bgsave执行完毕之后，发送RDB文件到slave，slave执行

5、master发送缓存中的写命令到slave，slave执行

这里我写的这个命令是sync，但是在redis2.8版本之后已经使用psync来替代sync了，原因是sync命令非常消耗系统资源，而psync的效率更高。

9.2、应用高可用

9.2.1、哨兵模式

基于主从方案的缺点还是很明显的，假设master宕机，那么就不能写入数据，那么slave也就失去了作用，整个架构就不可用了，除非你手动切换，主要原因就是因为没有自动故障转移机制。而哨兵(sentinel)的功能比单纯的主从架构全面的多了，它具备自动故障转移、集群监控、消息通知等功能。

哨兵可以同时监视多个主从服务器，并且在被监视的master下线时，自动将某个slave提升为master，然后由新的master继续接收命令。整个过程如下：

1、初始化sentinel，将普通的redis代码替换成sentinel专用代码

2、初始化masters字典和服务器信息，服务器信息主要保存ip:port，并记录实例的地址和ID

3、创建和master的两个连接，命令连接和订阅连接，并且订阅sentinel:hello频道

4、每隔10秒向master发送info命令，获取master和它下面所有slave的当前信息

5、当发现master有新的slave之后，sentinel和新的slave同样建立两个连接，同时每个10秒发送info命令，更新master信息

6、sentinel每隔1秒向所有服务器发送ping命令，如果某台服务器在配置的响应时间内连续返回无效回复，将会被标记为下线状态

7、选举出领头sentinel，领头sentinel需要半数以上的sentinel同意

8、领头sentinel从已下线的的master所有slave中挑选一个，将其转换为master

9、让所有的slave改为从新的master复制数据

10、将原来的master设置为新的master的从服务器，当原来master重新回复连接时，就变成了新master的从服务器

sentinel会每隔1秒向所有实例（包括主从服务器和其他sentinel）发送ping命令，并且根据回复判断是否已经下线，这种方式叫做主观下线。当判断为主观下线时，就会向其他监视的sentinel询问，如果超过半数的投票认为已经是下线状态，则会标记为客观下线状态，同时触发故障转移。

9.2.2、cluster集群模式

如果说依靠哨兵可以实现redis的高可用，如果还想在支持高并发同时容纳海量的数据，那就需要redis集群。redis集群是redis提供的分布式数据存储方案，集群通过数据分片sharding来进行数据的共享，同时提供复制和故障转移的功能。

一个redis集群由多个节点node组成，而多个node之间通过cluster meet命令来进行连接，节点的握手过程：

1. 节点A收到客户端的cluster meet命令
2. A根据收到的IP地址和端口号，向B发送一条meet消息
3. 节点B收到meet消息返回pong
4. A知道B收到了meet消息，返回一条ping消息，握手成功
5. 最后，节点A将会通过gossip协议把节点B的信息传播给集群中的其他节点，其他节点也将和B进行握手

槽slot

redis通过集群分片的形式来保存数据，整个集群数据库被分为16384个slot，集群中的每个节点可以处理0-16383个slot，当数据库16384个slot都有节点在处理时，集群处于上线状态，反之只要有一个slot没有得到处理都会处理下线状态。通过cluster addslots命令可以将slot指派给对应节点处理。

slot是一个位数组，数组的长度是16384/8=2048，而数组的每一位用1表示被节点处理，0表示不处理，如图所示的话表示A节点处理0-7的slot。

当客户端向节点发送命令，如果刚好找到slot属于当前节点，那么节点就执行命令，反之，则会返回一个MOVED命令到客户端指引客户端转向正确的节点。（MOVED过程是自动的）

如果增加或者移出节点，对于slot的重新分配也是非常方便的，redis提供了工具帮助实现slot的迁移，整个过程是完全在线的，不需要停止服务。

故障转移

如果节点A向节点B发送ping消息，节点B没有在规定的时间内响应pong，那么节点A会标记节点B为pfail疑似下线状态，同时把B的状态通过消息的形式发送给其他节点，如果超过半数以上的节点都标记B为pfail状态，B就会被标记为fail下线状态，此时将会发生故障转移，优先从复制数据较多的从节点选择一个成为主节点，并且接管下线节点的slot，整个过程和哨兵非常类似，都是基于Raft协议做选举。

十、了解Redis事务机制吗？

十一、Redis的使用场景

1、内存数据库

2、计数器：

3、分布式锁：

4、排行榜：通过list取最新的N条数据

5、token这种需要设置过期时间的场景

6、消息的发布订阅

十二、Redis真的是单线程的吗？

Redis6.0之前是单线程的，Redis6.0之后开始支持多线程；

redis内部使用了基于epoll的多路复用，也可以多部署几个redis服务器解决单线程的问题；

redis主要的性能瓶颈是内存和网络；

内存好说，加内存条就行了，而网络才是大麻烦，所以redis6内存好说，加内存条就行了；

而网络才是大麻烦，所以redis6.0引入了多线程的概念，

redis6.0在网络IO处理方面引入了多线程，如网络数据的读写和协议解析等，需要注意的是，执

命令的核心模块还是单线程的。

十三、Redis和 memecache 有什么区别？

13.1、持久化

13.2、数据结构的多样性

13.3、分布式集群部署

十四、Redis分布式锁有什么缺陷？

Redis 分布式锁不能解决超时的问题，分布式锁有一个超时时间，程序的执行如果超出了锁的超时时间就会出现问题。

Redis容易产生的几个问题：

1、锁未被释放

2、B锁被A锁释放了

3、数据库事务超时

4、锁过期了，业务还没执行完

5、Redis主从复制的问题

十五、Redis如何做内存优化？

可以好好利用Hash,list,sorted set,set等集合类型数据，因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面

15.1、缩短键值的长度

缩短值的长度才是关键，如果值是一个大的业务对象，可以将对象序列化成二进制数组；
首先应该在业务上进行精简，去掉不必要的属性，避免存储一些没用的数据；
其次是序列化的工具选择上，应该选择更高效的序列化工具来降低字节数组大小；
以JAVA为例，内置的序列化方式无论从速度还是压缩比都不尽如人意，这时可以选择更高效的序列化工具，如: protostuff，kryo等

15.2、共享对象池

对象共享池指Redis内部维护[0-9999]的整数对象池。创建大量的整数类型redisObject存在内存开销，每个redisObject内部结构至少占16字节，甚至超过了整数自身空间消耗。所以Redis内存维护一个[0-9999]的整数对象池，用于节约内存。 除了整数值对象，其他类型如list,hash,set,zset内部元素也可以使用整数对象池。因此开发中在满足需求的前提下，尽量使用整数对象以节省内存。

3、字符串优化

4、编码优化

5、控制key的数量

十六、Redis有哪些优缺点

优点

• 读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。

• 支持数据持久化，支持AOF和RDB两种持久化方式。

• 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。

• 数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点

• 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

• Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

• Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

• 涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）。

• 同时操作多个key,则不能使用Redis事务.

• 分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集（The partitioning granularity is the key, so it is not possible to shard a dataset with a single huge key like a very big sorted set）

• 当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的Redis实例和主机同时收集RDB / AOF文件。

• 分区时动态扩容或缩容可能非常复杂。Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。然而，有一种预分片的技术也可以较好的解决这个问题。

十八、Redis线程模型

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器（file event handler）。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

• 文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。

• 当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时， 与操作相对应的文件事件就会产生， 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器以单线程方式运行， 但通过使用 I/O 多路复用程序来监听多个套接字， 文件事件处理器既实现了高性能的网络通信模型， 又可以很好地与 redis 服务器中其他同样以单线程方式运行的模块进行对接， 这保持了 Redis 内部单线程设计的简单性。