Redis面试

一、Redis简介

Mysql的数据都存放在磁盘中，读取时IO压力大，所以缓存数据库应运而生。

1.缓存中间件—Memcache和Redis的区别

Memcache：代码层次类似Hash

1. 支持简单数据类型
2. 不支持数据的持久化存储
3. 不支持主从
4. 不支持分片

Redis

1. 数据类型丰富
2. 支持数据磁盘持久化存储
3. 支持主从
4. 支持分片

2.为什么Redis这么快

Redis可以达到100000+QPS。

1. 完全基于内存，绝大部分请求是纯粹的内存操作
2. 数据结构简单，对数据操作也简单
3. 采用单线程，避免了处理并发问题。单线程也能处理高并发请求。
4. 使用多路I/O复用模型，非阻塞IO。

3.多路I/O复用模型

文件描述符：一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件的元数据到文件本身的映射。

传统的阻塞I/O模型

当对一个FD进行读写时，如果当前FD不可用，服务就不会对其它操作做出响应，导致整个服务不可用。

Select系统调用

Selector可以监控多个文件描述符的可读可写情况，当某些文件描述符可读/可写时，Selector就会返回这些文件描述符的个数。如果没有可用的，程序就可以去做别的事情而不用阻塞。

多路复用函数

1. Redis会根据编译平台的不同，选择不同的多路I/O复用函数。
2. 优先选择时间复杂制度为O(1)的I/O多路复用函数作为底层实现。
3. 以时间复杂度为O(n)的select作为保底
4. 基于react设计模式监听I/O事件。

二、Redis常用数据类型

1.字符串String

最基本的数据类型，是二进制安全的（可以保存图片等文件）
保存字符串对象的结构：sdshdr。

struct sdshdr{
	//buf中已占用空间的长度
	int len;
	//buf中剩余可用空间的长度
 	int free;
 	//数据空间
 	char buf[];
 }

2.哈希Hash

String元素组成的字典，适合用于存储对象。

3.列表List

按照String元素插入顺序排序。

4.集合Set

String元素组成的无序集合，通过哈希表实现。

5.有序集合Zset

设置时可以添加double类型的分数，通过分数来为集合中的成员进行从小到大的排序。

三、从海量key里查询出某一固定前缀的Key

摸清数据规模，问清楚边界，再结合实际作答。

1.使用keys指令

使用keys pattern就可以查看给定模式的key列表。
keys会一次性返回所有匹配的key，如果键的数量过大，会导致程序阻塞。在线上服务使用会导致卡顿。

2.scan指令

scan可以无阻塞地提取出指定模式的key列表。使用方式：SCAN cursor [MATCH pattern] [COUNT count]。

scan是基于游标的迭代器，每一次迭代都需要基于上一次游标，延续之前的迭代过程。一次返回的数量不可控，只能是大概率符合count参数。

四、通过Redis实现分布式锁

1.分布式锁需要解决的问题

1. 互斥性：同一时刻只能有一个客户端获取到锁
2. 安全性：锁只能被持有该锁的客户端删除
3. 死锁：持有锁的客户端宕机导致无法释放锁，需要有解决方法
4. 容错：部分节点宕机客户端依然可以获取/释放锁

2.SETNX

SETNX key value：如果key不存在，则创建并赋值。成功返回1，失败返回0。

初期可以被用来实现分布式锁，执行代码逻辑时尝试用SETNX设置key，成功才能继续执行。

怎么释放锁？通过设置过期时间让key失效：EXPIRE key seconds

有什么问题？如果获取锁后还没来得及设置expire就挂掉了，那么这个锁将一直被该客户端持有无法释放。

3.set

上面的方式之所以不安全，是因为setnx与expire不是原子的。6.12版本后，可以通过以下命令将二者结合起来：
SET key value [EX seconds] [PX milliseconds] [NX|XX] EX是秒，PX是毫秒

五、通过Redis实现异步队列

1.List实现

使用List作为队列，RPUSH生产消息，LPOP消费消息。

• 缺点：LPOP不会等队列里有值才消费；
• 解决：在应用层引入Sleep机制调用LPOP重试。

2.BLPOP

不用Sleep可以使用BLPOP指令，BLPOP key [key ...] timeout：阻塞直到队列有消息或超时。

3.一对多

使用pub/sub：主题订阅者模式。订阅者可以订阅多个频道。
客户端使用subscribe 频道名订阅，使用publish 频道名 消息发布内容。

六、Redis持久化

如果数据保存在内存里，则断电就会消失。所以要对重要数据持久化存储，Redis持久化有三种方式：

1.RDB（快照）持久化：保存某个时间点的全量数据快照

（1）手动创建

RDB文件可以通过两个命令来创建：

• SAVE：阻塞Redis服务器进程，直到RDB文件被创建完毕（少被使用）
• BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程。

（2）自动创建

除手动方式，RDB也会自动触发：

1. 根据redis.conf配置里的SAVE m n定时触发（用的是BGSAVE）
2. 主从复制时，主节点自动触发
3. 执行Debug Reload
4. 执行Shutdown且没有开启AOF持久化

（3）BGSAVE原理

执行BGSAVE指令后，会先检查有没有正在执行的AOF或RDB子进程，有则报错。没有则会调用rdbSaveBackground方法，系统调用fork()，创建进程，实现了Copy-on-Write。

（4）缺点

1. 内存数据的全量同步，数据量大会由于I/O而严重影响性能。
2. 可能会因为Redis挂掉从而丢失从当前至最近一次快照期间的数据。

2.AOF（Append-Only-File）持久化：保存写状态

（1）实现

1. 记录下除了查询以外的所有变更数据库状态的指令；
2. 以append的形式追加保存到AOF文件中（增量）。

（2）AOF文件大小不断增大的问题

使用日志重写解决，原理如下：

1. 调用fork()，创建一个子进程；
2. 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件；
3. 主进程持续将新的变动同时写到内存和原来的AOF文件中；
4. 主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动；
5. 使用新的AOF文件替换掉旧的AOF文件。

3.Redis数据恢复

RDB和AOF文件共存情况下的恢复流程：

四、RDB和AOF的优缺点

• RDB优点：全量数据快照，文件小，恢复快
• RDB缺点：无法保存最近一次快照之后的数据
• AOF优点：可读性高，适合保存增量数据，数据不易丢失
• AOF缺点：文件体积大，恢复时间长

五、混合模式

结合RDB与AOF：

• BGSAVE做镜像全量持久化，AOF做增量持久化

六、Pipeline

Pipeline和Linux的管道类似。
Redis基于请求/响应模型，单个请求处理需要一一应答。Pipeline批量执行指令，节省多次IO往返时间。