Redis面试常问总结

我是方圆
Redis基于内存，你我基于什么呢？

1. Memcache和Redis

• Memcache
  支持简单的数据类型
  不支持数据持久化
  不支持主从
  不支持分片
• Redis
  数据类型丰富
  支持数据磁盘持久化
  支持主从
  支持分片

2. Redis为什么这么快？

• 完全基于内存，请求是基于内存的操作，执行效率高
• 数据结构简单，对数据操作也简单
• 采用单线程，单线程也能处理高并发请求
• 使用多路I/O复用模型，非阻塞IO

3. 使用KEYS命令对线上业务的影响

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

4. 如何实现分布式锁

1. 使用SETNX key value和EXPIRE key seconds组合
   
   但是，单条命令是原子性的，两条命令若结合在一起，便不具备原子性，如若在执行完SETNX后，出现宕机，那么key则成了永久的key，使得其他线程无法对其进行操作
2. 使用SET key value [EX seconds] [PX milliseconds] [NX|XX]
   这一条命令便结合了上方两条命令，EX是秒，PX是毫秒，NX为键不存在时进行操作，XX只有键存在时，才进行操作

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

• 集中过期，由于要清理大量的key很耗时，会出现短暂的卡顿现象
• 解决方法：在设置key的时候，给每个key加上随机的过期时间

6. 如何使用Redis做异步队列

1. 使用List作为消息队列，RPUSH生产消息，LPOP消费消息
缺点：没有等待机制，队列里没有消息也进行消费
   弥补：可以在应用层引入sleep机制来调用LPOP
2. 对1.的完善，BLPOP key[key...] timeout ：阻塞直到有消息或者等待固定的时间
   缺点：只能供一个消费者进行消费
3. 对2.的完善，使用pub/sub
   
   通过subscribe可以订阅消息，通过publish来发布消息给订阅的人
   缺点：消息是无状态的，无法保证消息一定可达

7. RDB持久化和AOF持久化

7.1 RDB(保存的是某一时间点的全量数据快照)

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

7.1.1 自动触发RDB持久化的方式

1. 根据Rdis配置文件redis.conf中的SAVE m n配置，定时触发（BGSAVE)
2. 主从复制时，主节点自己插法
3. 执行DeBug Reload
4. 执行ShutDown但没有开启AOF时触发

7.1.2 BGSAVE原理图

缺点：内存数据全量同步，数据很大由于I/O而严重影响性能；可能会因为服务器宕机而丢失数据

7.1.3 RDB优缺点

7.2 AOF

7.2.1 AOF实现过程

7.2.2 AOF文件生成条件

7.2.3 AOF优缺点

7.3 RDB和AOF共存时，数据恢复过程