面：缓存中间件——Memcached和Redis的区别是什么？
答：Memcached的优点是简单易用，代码层次类似与Hash。支持简单数据类型，但不支持数据持久化存储，也不支持主从同步，也不支持分片。Redis的数据类型丰富，支持数据磁盘持久化存储，支持主从，支持分片。
面：为什么Redis能这么快？（100000+QPS）
- 完全基于内存，不受限于磁盘I/O,绝大部分请求是纯粹的内存操作，执行效率高
- 数据结构简单，对数据操作也简单（不使用表，存储结构就是键值对）
- 采用单线程（主线程，多个线程对同一个键做写操作的时候，不会出现并发问题，避免了上下文的切换和锁竞争），单线程也能处理高并发请求，想多核也可以启动多实例
- 使用多路I/O复用模型，非阻塞IO
面：说说你用过的Redis的数据类型？
- String：最基本的数据类型，二进制安全
- Hash：String元素组成的字典，适合用于存储对象
- List：列表，按照String元素插入顺序排序
- Set：String元素组成的无序集合，通过哈希表实现，不允许重复
- Sorted Set（ZSet）：通过分数来为集合中的成员进行从小到大的排序
- 用于计数的HyperLogLog，用于支持存储地理位置信息的Geo
Redis底层数据类型基础：
- 简单动态字符串
- 链表
- 字典
- 跳跃表
- 整数集合
- 压缩列表
- 对象
面：如何从海量Key里查询出某一固定前缀的Key？
答：若使用KEYS pattern：查找出所有符合给定模式patter的key，会对使线上的业务造成卡顿（主要是一次性返回所有的满足条件的key），此时可以使用SCAN指令（SCAN cursor [MATCH pattern] [COUNT count]）无阻塞的返回一定数量的key（它是基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程；以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历；不保证每次执行都返回某个给定数量的元素，支持模糊查询。）
面：如何通过Redis实现简单的分布式锁？
分布式锁需要解决的问题：互斥性（任意时刻只能有一个客户端获取锁），安全性（锁只能由持有该锁的客户端释放），死锁（持有锁的客户端宕机后，无法释放锁，导致其他客户端无法获取到该锁导致的死锁），容错（当某些客户端宕机后，其他客户端也要能获取锁和释放锁）
答：缺陷方案：首先可以通过Redis命令SETNX key value（原子性的，如果可以不存在，则创建并赋值，时间复杂度O（1），设置成功返回1，失败返回0），若能设置成功则说明此时没有别的线程进入了临界区。若失败，则表明该资源已经被其他线程所占用了，所以需要一直等待，直到SETNX返回1即其他线程设置的key过期了（EXPIRE key seconds）。但是上述方案有个缺点：即SETNX 和 EXPIRE的复合操作不是原子性的，若某个线程执行完SETNX突然挂掉了，那么由于没有执行EXPIRE操作，那么独占资源就一直不能被其他线程所占用。
优秀方案：上述方案之所以有缺陷，是因为原子性没有得到满足，所以可以通过以下命令SET key value [EX secods] [PX milliseconds] [NX|XX]（这条命令就是同时满足SETNX和EXPIRE，SET操作成功时返回OK，否则返回nil）此条命令是原子操作。
面：如果有大量的Key同时过期，那么需要注意什么？
集中过期，由于清除大量的key会耗时，会出现短暂的卡顿现象。解决方案是在设置key的过期时间时，给每个key加上随机值，使得过期时间分散些。
面：如何使用Redis做异步队列？
答：使用List作为队列，RPUSH生产消息，LPOP消费消息。但是LPOP不会等待队列有值才消费它会一直尝试消费，可以同过引入Sleep机制调用LPOP重试。也可通过命令BLPOP key [key...] timeout(阻塞直到队列有消息或者超时)。缺点是：只能供一个消费者消费。如果要让多个消费者消费，就可以使用Redis里的pub/sub（主题订阅者模式），但是消息的发布是无状态的，无法保证可达（要解决这个问题，就需要使用专业的队列Kafka）。
面：Redis如何做持久化？
- RDB（快照）持久化：保存某个时间点的全量数据快照
- SAVE命令：阻塞Redis的服务器进程，直到RDB文件被创建完毕
- BGSAVE命令：Fork出一个子进程来创建RDB文件，不阻塞服务器进程
- 缺点是：由于是内存数据的全量同步，那么当数据量大时会由于I/O而严重影响性能；可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据
- AOF（Append-Only-File）持久化：保存写状态。记录除了查询以外的所有变更数据库状态的指令，以append的形式追加保存到AOF文件中（增量）
面：如何解决AOF文件大小不断增大的问题？
答：可以采取日志重写的方式，原理如下：
- 调用fork（），创建一个子进程
- 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件
- 主进程持续将新的变动同时写到内存和原来的AOF里（防止重写失败，保证数据的完整性）
- 主进程获取子进程重写AOF的完成信号往新AOF同步增量变动
- 使用新的AOF文件替换掉旧的AOF文件
面：当RDB和AOF文件共存的情况下，如何恢复Redis的数据？
面：谈谈RDB和AOF的优缺点？
- RDB优点：全量数据快照，文件小，恢复快
- RDB缺点：无法保存最近一次快照之后的数据
- AOF优点：可读性高，适合保存增量数据，数据不易丢失
- AOF缺点：文件体积大，恢复时间长
RDB-AOF混合持久化方式：BGSAVE做镜像全量持久化，AOF做增量持久化。
面：如何从海量数据里快速找到所需要的数据？
答：使用分片：按照某种规则去划分数据，使数据分散存储在多个节点上。并且Redis为了能够提高key的命中率，采用的是一致性hash算法（一致性hash算法：对2^32取模将hash值空间组织成虚拟的圆环，将数据key使用相同的hash函数计算出hash值，引入虚拟节点解决数据倾斜）。