一、Redis到底是单线程还是多线程
Redis 6.0版本之前的单线程指的是其网络I/O和键值对读写是由一个线程完成。
也就是只有网络请求模块和数据操作模块是单线程的，而其他的持久化、集群数据同步等，其实是由额外的线程执行的。
Redis6.0引入的多线程指的是网络请求过程采用了多线程，但键值对读写命令仍然是单线程处理的，所以Redis依然是并发安全的。
二、Redis单线程为什么还能这么快
- 命令执行是基于内存操作的，一天命令在内存里操作的时间是几十纳秒
- 命令执行是单线程操作，没有线程切换开销。
- 基于IO多路复用机制提升Redis的IO利用率。
- 高效的数据存储结构：全局hash表以及多种高效的数据结构，比如：跳表、压缩列表、链表等。
三、Redis底层数据是如何用跳表来存储的
四、Redis key 过期了为什么内存没释放
- 如果原本这个key是有过期时间的，再给这个key使用SET命令并且不设置过期时间，那么Redis会自动擦除这个key的过期时间。
Redis对于过期的key的处理一般有惰性删除和定时删除两种策略 - 惰性删除：当读/写一个已经过期的key时，会触发惰性删除策略，判断key是否过期，如果过期了直接删除这个key。这也是key过期了为什么没有立即释放内存。
- 定时删除：由于惰性删除无法保证冷数据被及时删掉，所以Redis会定期（默认每100ms）主动淘汰一批已过期的key，这里的一批只是部分过期的key，所以可能会出现key已经过期了但是还没有被清理掉的情况，导致内存没有释放。
五、Redis key没有设置过期时间为什么被Redis主动删除了
当Redis已用内存超过maxmemory限定时，厨房主动清理策略
主动清理策略在Redis4.0之前，实现了6种内存淘汰策略，在4.0之后，又增加了两种，总共8种：
六、Redis 淘汰key的算法LRU与LFU的区别
LRU算法（Least Recently Used，最近最少使用）：淘汰很久没被访问的数据，以最近一次访问时间作为参考。
LFU算法（Least Frequently Used，最不经常使用）：淘汰最近一段时间被访问次数最少的数据，以次数作为参考。
绝大多数情况我们可以用LRU策略，当存在大量的热点缓存数据时，LFU可能更好一点。
七、删除Key命令会阻塞Redis嘛
会阻塞的。DEL key[key...] 命令会根据key类型来删除，时间复杂度也是不一样的，O(N)，N为被删除的key数量
删除单个字符串类型的key，时间复杂度为O(1)
删除单个列表、集合、有序集合或哈希类型的key，时间复杂度为O(M)，M为以上数据结构内的元素数量。
八、Redis主从、哨兵、集群架构的优缺点比较
在Redis3.0以前的版本主要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点有异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用方面表现一般，特别在主从切换的瞬间存在访问瞬断的问题，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发量，且单个主节点的内存也不宜设置过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。
Redis集群是一个由多个主从节点群组组成的分布式服务集群，他具有复制、高可用、分片特性，Redis集群不需要sentinel哨兵，也能完成节点移除和故障转移的功能，需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展；Redis集群的性能和高可用均优于之前版本的哨兵模式，且集群配置非常简单。
九、谈谈Redis集群数据hash分片算法
Redis 集群将所有数据划分16384个slots，每个节点负责其中一部分槽位。当Redis 集群的客户端来连接集群时，它也会得到一份集群的槽位信息并将其缓存到客户端本地，这样当客户端要查找某个key时，可以根据槽位定位算法定位到目标节点。
槽位定位算法
集群默认会对key值使用crc16算法进行hash，得到一个整数值，然后这个整数值对16384进行取模运算来得到具体的槽位。
Hash_slot = CRC16(key)mod13684
再根据槽位和节点的对应关系就可以定位到key具体是在那个Redis节点上。
十、Redis执行命令竟然有死循环阻塞Bug
Redis有个RANDOMKEY命令可以从Redis中随机取出一个key，这个命令可能导致Redis死循环阻塞。
RANDOMKEY在随机拿出一个key之后，首先会检验这个key是否过期，如果该key过期，那么Redis会删除它，这个过程就是惰性删除，但是清理完了之后还不能结束，Redis会再找出一个没过期的key返回给客户端。
此时，Redis则会继续随机拿出一个key，然后再判断它是否过期，直到找到一个没过期的key返回给客户端。
这里就有一个问题，如果此时Redis中有大量的key过期，但还未来得及被清理掉，这个循环就会持续很久才能结束，这样就会导致RANDOMKEY命令执行耗时变长，影响Redis性能。
以上流程，其实是master上执行的。如果在slave上执行RANDOMKEY，那么问题更严重。
slave是不会自己清理过期的key，当一个key要过期时，master会先清理删除它，之后master向slave发送一个DEL命令，告知slave也删除这个key，以此达到主从一致。
假设Redis中存在大量已过期还未来得及清理的key，那么在slave上执行RANDOMKEY时，就会发生一下问题：
1、slave随机取出一个key，判断是否已经过期。
2、key已经过期，但是slave不会删除它，而是继续随机寻找不过期的key
3、由于大量key都已过期，那slave就会找不到符合条件的key，就会进入死循环。
这个Bug直到5.0才被修复，修复方法就是在slave中设置一个最大查找次数，无论找到与否，到了这个最大次数就退出循环。