Redis面试

一、Redis提供的8中淘汰策略

# volatile-lru -> 从设置了过期时间的数据中淘汰最久未使⽤的数据.
# allkeys-lru -> 从所有数据中淘汰最久未使⽤的数据.
# volatile-lfu -> 从设置了过期时间的数据中淘汰使⽤最少的数据.
# allkeys-lfu -> 从所有数据中淘汰使⽤最少的数据.
# volatile-random -> 从设置了过期时间的数据中随机淘汰⼀批数据.
# allkeys-random -> 从所有数据中随机淘汰⼀批数据.
# volatile-ttl -> 淘汰过期时间最短的数据.
# noeviction -> 不淘汰任何数据，当内存不够时直接抛出异常.

理解两个算法名词：
LRU 最久最近未使⽤
LFU 最近最少使⽤

二、Redis⾼频⾯试题

redis是单线程为什么那么快

1、完全基于内存，绝⼤部分请求是纯粹的内存操作，⾮常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的
时间复杂度都是O(1)；
2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进⾏设计的
3、采⽤单线程，避免了不必要的上下⽂切换和竞争条件，也不存在多进程或者多线程导致的切换⽽消耗 CPU，不⽤去考虑各种锁的问题，
不存在加锁释放锁操作，没有因为可能出现死锁⽽导致的性能消耗；
4、使⽤多路I/O复⽤模型，⾮阻塞IO；
（1）多路 I/O 复⽤模型
多路I/O复⽤模型是利⽤ select、poll、epoll 可以同时监察多个流的 I/O 事件的能⼒，在空闲的时候，会把当前线程阻塞掉，当有⼀个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询⼀遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了⼤量的⽆⽤操作。
这⾥“多路”指的是多个⽹络连接，“复⽤”指的是复⽤同⼀个线程。采⽤多路 I/O 复⽤技术可以让单个线程⾼效的处理多个连接请求
（尽量减少⽹络 IO 的时间消耗），且 Redis 在内存中操作数据的速度⾮常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主
要由以上⼏点造就了 Redis 具有很⾼的吞吐量。
 

1. 在项⽬中redis的使⽤场景

⽤于缓存⾸⻚数据

数据共享分布式。

分布式锁

2. Redis的持久化策略 

RDB（保存数据快照） 和AOF（保存数据操作）

1.RDB 的优势和劣势
优势：

RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。

生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

劣势：

RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

2、AOF 的优势和劣势
优势：

AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。

AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。

AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

缺点：

对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

3. Redis⽀持的数据类型

常用的5种数据类型

字符串(String)、列表(List)、散列(Hash)、集合(Set)、有序集合(Sorted Set)

类比java数据类型

• string --> String
• hash --> Hashmap
• list --> LinkList
• set --> HashSet
• sorted_set --> TreeSet

4. 如何保证redis的⾼可⽤

Redis⽀持持久化，同时开启rdb 和 aof ，以保证数据的安全性（还是存在数据丢失
⻛险的）
Redis⽀持主从配置，我们可通配置哨兵，实现主备配置，保证可⽤性
Redis也⽀持集群，通过集群配置可以保证redis的⾼并发

5. 你刚才提到了redis集群，请问如何解决redis集群的脑裂问题？

集群脑裂

redis 的集群脑裂是指因为网络问题，导致 redis master 节点跟 redis slave 节点和 sentinel 集群处于不同的网络分区，此时因为 sentinel 集群无法感知到 master 的存在，所以将 slave 节点提升为master 节点。此时存在两个不同的 master 节点，就像一个大脑分裂成了两个。
集群脑裂问题中，如果客户端还在基于原来的 master 节点继续写入数据，那么新的 master 节点将无法同步这些数据，当网络问题解决之后，sentinel 集群将原先的master节点降为 slave 节点，此时再从新的 master 中同步数据，将会造成大量的数据丢失。

2 解决方案
redis的配置文件中，存在两个参数：

min-replicas-to-write 3
min-replicas-max-lag 10

按照上面的配置，要求至少3个slave节点，且数据复制和同步的延迟不能超过10秒，否则的话master就会拒绝写请求，配置了这两个参数之后，如果发生集群脑裂，原先的master节点接收到客户端的写入请求会拒绝，就可以减少数据同步之后的数据丢失

redis中的异步复制情况下的数据丢失问题也能使用这两个参数。

6. redis中的数据可以设置过期时间，当数据过期之后有些key并没有及时清除，请问如何处理？

Redis 过期策略分为两种方式：被动方式和主动方式。

被动方式

惰性删除：定期删除策略可能会导致很多过期的key到了时间也还没有被删除掉；为了解决这个问题，redis增加了惰性删除策略；对于那些过期的key，靠定期删除策略没有被删除掉，还保留在内存中，这时候如果系统去主动查询这个key，redis判断已经过期了，才会把这个过期的key删除掉。

主动方式
当然只有被动方式是无法满足我们的要求的，如果key一直没有被访问，那这个key就会一直存在内存中，随着key的数据越来越多，内存也就被逐渐占满，影响使用，所以就引出了另一种删除过期key的方式主动方式。
主动方式又分为定期删除和定时删除:

1.定期删除
定期删除会定期在过期的key中随机抽样，然后把过期的key删除。定期任务的频率默认是每秒执行10次，

2.定时删除
在添加key的同时给key设置一个定时器，当过期时间到了的时候就立即删除过期key。

Redis 采用的是惰性删除和定期删除两种方式来删除过期的key。

仅仅靠通过设置过期时间还是存在着问题的。由于定期删除策略是随机抽取的，因此很有可能漏掉很多过期的key，这时候我们也没有主动去查询这些过期的key，因此也就没有使用惰性删除策略了，这时候如果有大量的过期key堆积，会导致内存被消耗完。要解决这个问题：可以使用redis 内存淘汰机制。