Redis面试题

缓存中间件----Memcache和Redis的区别

• Memcache：代码层次类似Hash

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

• Redis

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

为什么Redis能这么快？

100000+QPS(QPS即query per second,每秒内查询次数）

• 完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高
• 数据结构简单，对数据操作也简单
• 采用单线程，单线程也能处理高并发请求，想多核也可以启动多实例
• 使用多路I/O复用模型，非阻塞IO

多路I/O复用模型

FD: File Descriptor,文件描述符

• 一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件的元数据到文件本身的映射
  
  Redis采用的I/O多路复用函数：epoll/kqueue/evport/select?
• 因地制宜
• 优先选择时间复杂度为O(1)的I/O多路复用函数作为底层实现
• 以时间复杂度为O(n)的select作为保底
• 基于react设计模式监听I/O事件

说说你用过的Redis的数据类型

供用户使用的数据类型

• String: 最基本的数据类型，二进制安全
• Hash：String元素组成的字典，适合用于存储对象
• List：列表，按照String元素插入顺序排序
• Set：String元素组成的无序集合，通过哈希表实现，不允许重复
• Sorted Set：通过分数来为集合中的成员进行从小到大的排序
• 用于计数的HyperLoglog，用于支持存储地理位置信息的Geo
  

底层数据类型基础

1. 简单动态字符串
2. 链表
3. 字典
4. 跳跃表
5. 整数集合
6. 压缩列表
7. 对象

如何从海量Key里查询出某一固定前缀的Key？

留意细节

• 摸清数据规模，即问清楚边界

使用Keys对线上业务的影响

• Keys pattern：查找所有符合给定模式pattern的key
• KEYS指令一次性返回所有匹配的key
• 键的数量过大会使服务卡顿
  
• SCAN cursor [MATCH pattern] [ COUNT count ]
• 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
• 以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历
• 不保证每次执行都返回某个给定数量的元素，支持模糊查询
• 一次返回的数量不可控，只能是大概率符合count参数

如何通过Redis实现分布式锁

分布式锁需要解决的问题

• 互斥性
• 安全性
• 死锁
• 容错

SETNX key value：如果key不存在，则创建并赋值

• 时间复杂度：O(1)
• 返回值：设置成功，返回1；设置失败，返回0.

如何解决SETNX长期有效的问题

EXPIRE key seconds

• 设置key的生存时间，当key过期时(生存时间为0)，会被自动删除
• 缺点：原子性得不到满足

SET key value [EX seconds] [PX milliseconds] [NX|XX]

• EX second：设置键的过期时间为second秒
• PX millisecond：设置键的过期时间为 millisecond毫秒
• NX：只在键不存在时，才对键进行设置操作
• XX：只在键已经存在是，才对键进行设置操作
• SET操作成功完成时，返回OK, 否则返回nil
  

RedisService redisService=SpringUtils.getBean(RedisService.class);
String result=redisService.set(lockKey,requestId,SET_IF_NOT_EXIST,SET_WITH_EXPIRE_TIME,requireTime);
	if("OK".equals(result)){
     
		//执行独占资源逻辑
		doOcuppiedWork();
	}

大量的key同时过期的注意事项

集中过期，由于清除大量的key很耗时，会出现短暂的卡顿现象

• 解决方案：在设置key的过期时间的时候，给每个key加上随机值

如何使用Redis做异步队列

1. 使用List作为队列,RPUSH生产消息，LPOP消费消息

• 缺点：没有等待队列里有值就直接消费
• 弥补：可以通过在应用层引入Sleep机制取调用LPOP重试
  

2. BLPOP key[key…] timeout:阻塞直到队列有消息或者超时

• 缺点：只能供一个消费者消费

开启一个redis客户端，监听队列testlist30秒

开启另一个redis客户端，向队列push aaa

3. 如何使生产的消息给多个消费者消费？

pub/sub：主题订阅者模式

• 发送者（pub）发送消息，订阅者（sub）接收消息
• 订阅者可以订阅任意数量的频道

缺点：消息的发布是无状态的，无法保证可达

Redis如何做持久化

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

• SAVE：阻塞Redis的服务器进程，直到RDB文件被创建
• BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程

save 900 1  #900秒之内有一条写入，产生一次快照，备份
save 300 10 #300秒之内有10条写入，产生一次快照，备份
save 60 10000 #60秒之内有10000条写入，产生一次快照，备份

#当备份进程出错时，主进程停止新的写入操作
stop-writes-on-bgsave-error yes
#备份时需要将rdb文件压缩后再保存
rdbcompression yes

2. 自动化触发RDB持久化的方式

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

BGSAVE原理：

系统调用fork()：创建进程，实现了Copy-on-Write

RDB持久化

缺点：

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

Redis如何做持久化

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

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

# 是否开启aof
appendonly yes

#文件名称
appendfilename "appendonly.aof"

# 同步方式
appendfsync everysec

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

#加载aof时如果有错如何处理
aof-load-truncated yes

#文件重写策略
aof-rewrite-incremental-fsync yes

日志重写解决AOF文件大小不断增大的问题，原理如下：

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

Redis数据的恢复

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

RDB和AOF的优缺点

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

RDB-AOF混合持久化方式

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

看了上面的RDB和AOF的介绍后，我们可以发现，使用RDB持久化会有数据丢失的风险，但是恢复速度快，而使用AOF持久化可以保证数据完整性，但恢复数据的时候会很慢。于是从Redis4之后新增了混合AOF和RDB的模式，先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB何AOF两部分恢复数据，即保证了数据完整性，又提高了恢复的性能。

开启混合模式后，每当bgrewriteaof命令之后会在AOF文件中以RDB格式写入当前最新的数据，之后的新的写操作继续以AOF的追加形式追加写命令。当redis重启的时候，加载 aof 文件进行恢复数据：先加载 rdb 的部分再加载剩余的 aof部分。

使用Pipeline的好处

• Pipeline和linux的管道类似
• Redis基于请求/响应模型，单个请求处理需要一一应答
• Pipeline批量执行指令，节省多次IO往返时间
• 有顺序依赖的指令建议分批发送

Redis的同步机制

主从同步原理

全同步过程

• Slave发送sync命令到Master
• Master启动一个后台进程，将Redis中的数据快照保存到文件中
• Master将保存数据快照期间接收到的写命令缓存起来
• Master完成写文件操作后，将该文件发送给Salve
• 使用新的AOF文件替换掉旧的AOF文件
• Master将这期间收集的增量写命令发送给Salve端

增量同步过程

• Master接收到用户的操作指令，判断是否需要传播到Slave
• 将操作记录追加到AOF文件
• 将操作传播到其他Slave：1、对齐主从库；2、往响应缓存写入指令
• 将缓存中的数据发送给Slave’

Redis Sentinel

解决主从同步Master宕机后的主从切换问题

• 监控：检查主从服务器是否正常运行
• 提醒：通过API向管理员或者其他应用程序发送故障通知
• 自动故障迁移：主从切换

流言协议Gossip

在杂乱无章中寻求一致

• 每个节点都随机地与对方通信，最终所有节点的状态达成一致
• 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
• 不保证信息一定会传递给所有节点，但是最终会趋于一致

Redis的集群原理

如何从海量数据里快速找到所需？

• 分片：按照某种规则去划分数据，分散存储在多个节点上
• 常规的按照哈希划分无法实现节点的动态增减