Redis面试知识点（常见数据结构，淘汰策略，持久化机制，使用场景，AOF重写原理）

Redis复习知识点(一）

Redis是单线程还是多线程的？

• redis4之前redis是完全单线程的
• redis4.0时引入了多线程，但是只是用来做后台处理，核心流程还是完全单线程的。（接受命令、解析命令、执行命令、返回结果等）
• redis6.0多线程用于网络IO阶段，在接受命令和写会结果阶段，执行命令时还是单线程的。

redis是基于内存的，redis的瓶颈最有可能是机器的内存大小或者网络带宽。，使用多线程会造成额外的性能开销

为什么redis使用单线程也很快？

1. Redis是基于内存的操作
2. Redis使用IO多路复用模型，开发了自己的网络事件处理器。
3. 单线程操作避免了频繁的上下文操作

redis使用使用场景

缓存、分布式锁(set+lua脚本)，排行榜(zset)，计数，消息队列，地理位置，访客统计（hyperloglog）

Redis常见数据结构

• String：字符串
• List：列表
• Hash：哈希对象
• Set：集合
• Sorted Set：有序集合，set基础上增加了分值。

高级数据结构：

1. Hyper log log：通常用于基数统计（例如，网站访客统计）
2. Bitmap：位图
3. Stream：主要用于消息队列，类似于Kafka，可以认为是pub/sub的改进版。提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据,并能记住每一个客户端的访问位置，并保证消息不丢失。
4. Geo：redis3.2新特性，可以将用户给定的地理位置信息存储起来

redis删除过期数据的策略

• 惰性删除
  • 每次获取键时都检查键是否过期，如果过期就删除该键，但是堆内存不太友好。
• 定时删除
  • 用一个定时器来负责监视key，是否有过期的key，有就删除
• 定期删除+惰性删除
  • 默认时间为100ms，程序就对数据进行一次检查，并不是每100ms就将所有的key都检查一次，而是随机抽取进行检查，再配合上惰性删除，redis的性能就会提升。

Redis内存淘汰策略

当redis的内存空间已经用满时，redis将根据配置的驱逐策略进行相应的淘汰

1. neoviction：默认策略，不淘汰任何key，直接返回错误
2. 在已设置了过期时间的key中，选择最近最少使用的key进行淘汰
3. 在已设置过期时间的key中，选择将要过期的key进行淘汰
4. 在已设置过期时间的key中，随机选择key进行淘汰
5. 在所有key中，选择最近最少使用的key进行淘汰
6. 在所有key中，随机选择key进行淘汰
7. 禁止淘汰数据

淘汰算法

• FIFO：先进先出，新访问的数据插入FIFO队列尾部，数据在FIFO队列中顺序移动，淘汰FIFO队列头部的数据
• LRU：最近最少使用，判断最近被使用的时间，目前最远的数据优先被淘汰。
  • 新数据插入到链表尾部，每当缓存数据被访问，则将数据移到链表头部，当链表满时，将立案表尾部的数据丢弃
• LFU：最不经常使用，在一段时间内，数据被使用次数最少的，优先被淘汰
  • 把数据加入到链表中，按频次排序，一个数据被访问过，把它的频次+1，发生淘汰时，把频次低的淘汰掉。

Redis的持久化机制

Redis的持久化机制有：RDB、AOF、混合持久化（RDB+AOF）（Redis4.0引入）

• RDB：
  • 类似于快照，在指定的时间间隔内，将数据库的状态保存到一个RDB文件中，RDB持久化所生成的文件是一个压缩的二进制文件。
  • 有两个Redis命令可以用于生成一个RDB文件，一个是save，另一个是bgsave。
    • save命令会直接阻塞服务器进程，而bgsave会生成一个子进程然后由子进程创建RDB文件，主进程仍然可以继续处理命令请求。
  • 用户可以通过设置save选项，让服务器每隔一段时间自动执行一个bgsave命令。
    • redis默认的设置为：
      1. save 900 1 # 900秒内有一个key修改，就执行保存命令
      2. save 300 10
      3. save 60 10000
    • 当任意一个保存条件被满足时就会自动执行bgsave命令。
  • RDB的优点：
    • RDB文件是经过压缩的二进制文件，占用空间小
    • 再恢复大数据集时的速度比AOF快
    • RDB可以最大化redis的性能
  • RDB缺点：
    • RDB在服务器出现故障时容易造成数据的丢失，用户可以通过自己配置来控制持久化的频率，如果太频繁就会影响redis的性能。通常设置5分钟，如果Redis出现宕机的情况，最多只会丢失5分钟的数据。
• AOF：
  • 以日志的形式记录服务器所处理的每一个写、删除操作，以文本的方式记录，并在服务器启动时，通过重新执行这些命令来还原数据集。
  • AOF默认是关闭的。
  • AOF优点
    • AOF重写可以产生一个新的AOF文件，这个新的文件比旧的AOF文件小，但保存的数据状态一样。
    • AOF支持秒级持久化，就算服务器故障，也只会丢失1秒钟的数据。
      • 为了提高文件的写入效率，现代操作系统中用户调用写入命令时，会先将数据写入到缓冲区中，然后系统提供了同步的函数，来讲缓冲区的数据同步到文件中。
      • redis的同步选项有三个默认是如果距离上次同步aof文件的操作超过1秒钟，就再次对文件进行同步
  • 缺点
    • 相同的数据集，文件大小一般比RDB大。
    • 数据恢复比rdb慢。
• 混合持久化
  • 混合持久化只发生于AOF重写的过程中，重写后的AOF文件前半段是RDB格式的海量数据，后半段是AOF格式的增量数据。

AOF当用户执行写入或者删除命令时，操作系统通常会将

AOF重写功能的原理

首先从数据库中读取键当前时刻的值，然后用一条命令区记录键值对，代替之前记录这个键值对的多条命令。

原先往set中三次一共添加了三个值，重写时，先读取数据库中set的值，然后一次性往set中添加这三个值，这样就减少了数据冗余只需要一条命令就保存了数据库当前的状态。

为什么需要AOF重写文件

因为aof是以日志的形式追加文件的，随着写入命令的不断增加，AOF文件中的内容会越来越多，文件的体积也会也来越大，所以需要AOF重写文件来避免对redis服务器造成影响。

AOF后台重写的原理，如何解决AOF后台重写后造成的数据不一致问题。

AOF重写会有大量的写入操作（因为redis的命令需要在客户端上下文中执行，因此redis在执行重写时会生成一个不带网络连接的伪客户端来执行redis命令，为什么不带网络连接呢?因为重写时根据原先的aof文件进行的文不是网络连接），如果使用主线程来执行会被长时间阻塞而不能处理用户请求，所以redis决定将重写操作放在一个子进程中执行。

这样做服务器的主进程仍然可以继续处理命令请求，但是在子进程重写的过程中主进程可能会处理新的写入命令，从而导致数据库状态和重写后的状态不一致的情况。

为了解决这个问题，Redis服务器设置了一个AOF 重写缓冲区，这个重写缓冲区在服务器创建子进程之后开始使用。这个时候服务器在继续处理命令请求时会进行如下三个操作：

1. 执行客户端的命令
2. 将执行后的命令追加到AOF缓冲区中
3. 将执行后的写命令追加到AOF重写缓冲区中。

子进程在后台重写的过程中，主进程执行的写入命令会追加到重写缓冲区中，在子进程执行完会后会给主进程发送一个信号，主进程收到这个信号后，执行一个信号处理函数（会对服务器进程造成阻塞），来将重写缓冲区中的数据追加到新的AOF文件中，这时新的AOF文件所保存的数据库状态将和服务器中数据库的状态保持一致。