Redis常见面试问题总结

1. Redis是什么？

Redis是C语言开发的一个开源的（遵从bsd协议）的高性能键值对（key-value）的内存数据库，可以用作数据库，缓存，消息中间件, 它是一种NoSQL（泛指非关系型数据库）的数据库。从特点出发来看，有以下几个：

a. 性能优秀，数据在内存中，读写速度非常快，支持并发10W QPS(每秒查询率)。

b. 单进程单线程，是线程安全的，采用IO多路复用机制。

c. 丰富的数据类型，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等。

d. 支持数据持久化, 可以将内存中数据保存在磁盘中，重启时加载。

e. 主从复制，哨兵，高可用。

f. 可以用作分布式锁, 可以作为消息中间件使用，支持发布订阅。

 

2. 五种数据类型

有必要先来了解下 Redis 内部内存管理是如何描述这 5 种数据类型的。

首先 Redis 内部使用一个 redisObject 对象来表示所有的 key 和 value。redisObject 最主要的信息如上图所示：type 表示一个 value 对象具体是何种数据类型，encoding 是不同数据类型在 Redis 内部的存储方式。比如：type=string 表示 value 存储的是一个普通字符串，那么 encoding 可以是 raw 或者 int。

a. String 是 Redis 最基本的类型，可以理解成与 Memcached一模一样的类型，一个 Key 对应一个 Value。Value 不仅是 String，也可以是数字。String 类型是二进制安全的，意思是 Redis 的 String 类型可以包含任何数据，比如 jpg 图片或者序列化的对象。String 类型的单个值最大能存储 512M。

b. Hash是一个键值（key-value）的集合。Redis 的 Hash 是一个 String 的 Key 和 Value 的映射表，Hash 特别适合存储对象。常用命令：hget，hset，hgetall 等。

c. List 列表是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边） 常用命令：lpush、rpush、lpop、rpop、lrange（获取列表片段）等。应用场景：List 应用场景非常多，也是 Redis 最重要的数据结构之一，比如 Twitter 的关注列表，粉丝列表都可以用 List 结构来实现。数据结构：List 就是链表，可以用来当消息队列用。Redis 提供了 List 的 Push 和 Pop 操作，还提供了操作某一段的 API，可以直接查询或者删除某一段的元素。实现方式：Redis List 的是实现是一个双向链表，既可以支持反向查找和遍历，更方便操作，不过带来了额外的内存开销。

d. Set 是 String 类型的无序集合。集合是通过 hashtable 实现的。Set 中的元素是没有顺序的，而且是没有重复的。常用命令：sdd、spop、smembers、sunion 等。应用场景：Redis Set 对外提供的功能和 List 一样是一个列表，特殊之处在于 Set 是自动去重的，而且 Set 提供了判断某个成员是否在一个 Set 集合中。

e. Zset 和 Set 一样是 String 类型元素的集合，且不允许重复的元素。常用命令：zadd、zrange、zrem、zcard 等。使用场景：Sorted Set 可以通过用户额外提供一个优先级（score）的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择 Sorted Set 结构。和 Set 相比，Sorted Set关联了一个 Double 类型权重的参数 Score，使得集合中的元素能够按照 Score 进行有序排列，Redis 正是通过分数来为集合中的成员进行从小到大的排序。实现方式：Redis Sorted Set 的内部使用 HashMap 和跳跃表（skipList）来保证数据的存储和有序，HashMap 里放的是成员到 Score 的映射。而跳跃表里存放的是所有的成员，排序依据是 HashMap 里存的 Score，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

 

Redis数据应用场景类型总结：

 

Redis常见问题：

1. 在实际项目中使用缓存有遇到什么问题或者会遇到什么问题？

缓存和数据库数据一致性问题：分布式环境下非常容易出现缓存和数据库间数据一致性问题，针对这一点，如果项目对缓存的要求是强一致性的，那么就不要使用缓存。我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。合适的策略包括合适的缓存更新策略，更新数据库后及时更新缓存、缓存失败时增加重试机制。

 

2. 谈下Redis缓存雪崩？

所谓缓存雪崩简单来说就是redis中大规模（或者全部）key同时失效，让大量的请求全部直接打在了数据库上，打个比方就是如果首页所有 Key 的失效时间都是 12 小时，中午 12 点刷新的，零点有大量用户涌入，假设每秒 6000 个请求，本来缓存可以抗住每秒 5000 个请求，但是缓存中所有 Key 都失效了。此时 6000 个/秒的请求全部落在了数据库上，数据库必然扛不住，从而导致数据库挂了；同一时间大面积失效，瞬间 Redis 跟没有一样，那这个数量级别的请求直接打到数据库几乎是灾难性的。

如何解决：

a. 在批量往 Redis 存数据的时候，把每个 Key 的失效时间都加个随机值就好了，这样至少可以保证数据不会再同一时间大面积失效。

b. 如果 Redis 是集群部署，将热点数据均匀分布在不同的 Redis 库中也能避免全部失效。或者设置热点数据永不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，刷下缓存就好了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。

 

3. 缓存穿透与缓存击穿的区别。

缓存穿透：是指缓存和数据库中都没有的数据，而用户（黑客）不断发起请求。举例：数据库的 id 都是从 1 自增的，如果发起 id=-1 的数据或者 id 特别大不存在的数据，这样的不断攻击导致数据库压力很大，严重会击垮数据库。

缓存击穿：指的是单个热点key在不停的扛着大量的请求，大并发集中对这一个点进行访问，当这个key在失效的瞬间，那么就会导致大并发直接落到数据库上；

如何解决：

缓存穿透的话可以在接口层增加校验，比如用户鉴权，参数校验，不合法的参数直接return，比如ID做基础校验，不符合规则的直接拦截；再者就是使用布隆过滤器；

缓存击穿的话，设置热点数据不过期，或者加上互斥锁；

 

4. Redis为何这么快。

官方提供的数据可以达到 100000+ 的 QPS（每秒内的查询次数），因为redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是内存的大小或者是网络带宽。

a.Redis 完全基于内存，绝大部分请求是纯粹的内存操作，非常迅速，数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度是 O(1)。

b. 采用单线程，避免了不必要的上下文切换和竞争条件，不存在多线程导致的 CPU 切换，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有死锁问题导致的性能消耗。

c. 使用多路复用 IO 模型，非阻塞 IO。

 

5. Redis数据淘汰机制

6. Redis持久化。

Redis 的持久化策略有两种：

• RDB：快照形式是直接把内存中的数据保存到一个 dump 的文件中，定时保存，保存策略。

• AOF：把所有的对 Redis 的服务器进行修改的命令都存到一个文件里，命令的集合。Redis 默认是快照 RDB 的持久化方式。当 Redis 重启的时候，它会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存。

默认 Redis 是会以快照"RDB"的形式将数据持久化到磁盘的一个二进制文件 dump.rdb。工作原理简单说一下：当 Redis 需要做持久化时，Redis 会 fork 一个子进程，子进程将数据写到磁盘上一个临时 RDB 文件中。当子进程完成写临时文件后，将原来的 RDB 替换掉，这样的好处是可以 copy-on-write。

RDB 的优点是：这种文件非常适合用于备份：比如，你可以在最近的 24 小时内，每小时备份一次，并且在每个月的每一天也备份一个 RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB 非常适合灾难恢复。

RDB 的缺点是：如果你需要尽量避免在服务器故障时丢失数据，那么RDB不合适你。

 

使用 AOF 做持久化，每一个写命令都通过 write 函数追加到 appendonly.aof 中，配置方式如下：

AOF 可以做到全程持久化，只需要在配置中开启 appendonly yes。这样 Redis 每执行一个修改数据的命令，都会把它添加到 AOF 文件中，当 Redis 重启时，将会读取 AOF 文件进行重放，恢复到 Redis 关闭前的最后时刻。使用 AOF 的优点是会让 Redis 变得非常耐久。可以设置不同的 Fsync 策略，AOF的默认策略是每秒钟 Fsync 一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。缺点是对于相同的数据集来说，AOF 的文件体积通常要大于 RDB 文件的体积。根据所使用的 Fsync 策略，AOF 的速度可能会慢于 RDB。