Redis面试题

Redis是什么

Redis是C语言开发的一个开源的(遵从BSD协议)高性能键值对(key-value)的内存数据库,可以用作数据库、缓存、消息中间件等。它是一种NoSQL(not-only sql,泛指非关系型数据库)的数据库。

Redis作为一个内存数据库。 性能优秀,数据在内存中,读写速度非常快 , 单进程单线程,是线程安全的,采用IO多路复用机制;

丰富的数据类型,支持字符串(strings)、散列(hashes)、列表(lists)、集合(sets)、有序集合(sorted sets)等;

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

支持 主从复制,哨兵,高可用;

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

应用场景⭐

  1. 缓存
  2. 共享Session
  3. 消息队列系统
  4. 分布式锁

Redis 和 memcached 的区别

  1. redis支持更丰富的数据类型(支持更复杂的应用场景):Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,zset,hash等数据结构的存储。memcache支持简单的数据类型,String。
  2. Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中。
  3. 集群模式:memcached没有原生的集群模式,需要依靠客户端来实现往集群中分片写入数据;但是 redis 目前是原生支持 cluster 模式的.
  4. Memcached是多线程,非阻塞IO复用的网络模型;Redis使用单线程的多路 IO 复用模型。

redis 为什么是单线程的?

因为 cpu 不是 Redis 的瓶颈,Redis 的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现,而且 cpu 又不会成为瓶颈,那就顺理成章地采用单线程的方案了。 可以避免多线程上下文切换。

为什么Redis这么快?⭐

完全基于内存,绝大部分请求是纯粹的内存操作,执行效率高
采用单线程,单线程也能处理高并发请求,想多核也可启动多实例

单线程反而避免了多线程的频繁上下文切换问题,预防了多线程可能产生的竞争问题。

核心是基于非阻塞的 IO 多路复用机制。

Redis 支持的数据类型有哪些?应用?⭐

  1. String字符串:字符串类型是 Redis 最基础的数据结构,首先键都是字符串类型, Value 不仅是 String,也可以是数字。常用在缓存、计数、共享Session、限速等。
  2. Hash哈希:在Redis中,哈希类型是指键值本身又是一个键值对结构,哈希可以用来存放用户信息,比如实现购物车。
  3. List列表(双向链表):列表(list)类型是用来存储多个有序的字符串。可以做简单的消息队列的功能。 数据结构:List 就是链表,可以用来当消息队列用。Redis 提供了 List 的 Push 和 Pop 操作,还提供了操作某一段的 API,可以直接查询或者删除某一段的元素。 实现方式:Redis List 的是实现是一个双向链表,既可以支持反向查找和遍历,更方便操作,不过带来了额外的内存开销。
  4. Set集合:集合(set)类型也是用来保存多个的字符串元素,集合是通过 hashtable 实现的。 但和列表类型不一样的是,集合中不允许有重复元素,并且集合中的元素是无序的,不能通过索引下标获取元素。利用 Set 的交集、并集、差集等操作,可以计算共同喜好,全部的喜好,自己独有的喜好等功能。
  5. Sorted Set有序集合(跳表实现):Sorted Set 多了一个权重参数 Score,集合中的元素能够按 Score 进行排列。实现方式:Redis Sorted Set 的内部使用 HashMap 和跳跃表(skipList)来保证数据的存储和有序,HashMap 里放的是成员到 Score 的映射。

String 在你们项目怎么用的?

常用命令: set,get,decr,incr,mget 等。

在显示某个人的基本数据的时候,比如名字,粉丝数,关注数,使用 String 保存:

eg:  user:id:3506728370  
{"id":3506728370,"name":"春晚","fans":12210862,"blogs":6164, "focus":83}

设置一个定时刷新的操作,这样用户不需要直接读取数据库。怎么设置?setx key value,一定时间循环判断key是否失效,到期后再去数据库读取。

List 在你们项目怎么用的?

常用命令: lpush,rpush,lpop,rpop,lrange等

  1. 朋友圈点赞,要求按照点赞顺序显示点赞好友信息
    如果取消点赞,移除对应好友信息,但是不能使用pop了,怎么办呢?

    解决方案

    lrem key count value 移除指定数据
    count:移除的数目
    value:具体要移除的内容

  2. 个人用户的关注列表需要按照用户的关注顺序展示。

Set 在你们项目怎么用的?

每位用户首次使用今日头条时会设置3项爱好的内容,但是后期为了增加用户的活跃度、兴趣点,必须让用户
对其他信息类别逐渐产生兴趣,增加客户留存度,如何实现?

分析
系统分析出各个分类的最新或最热点信息条目并组织成set集合
随机挑选其中部分信息
配合用户关注信息分类中的热点信息组织成展示的全信息集合

解决方案

  • 随机获取集合中指定数量的数据

    srandmember key [count]

  • 随机获取集合中的某个数据并将该数据移出集合

    spop key [count]

zset

在直播系统中,实时排行信息包含直播间在线用户列表,各种礼物排行榜,弹幕消息(可以理解为按消息维度的消息排行榜)等信息,适合使用 Redis 中的 Sorted Set 结构进行存储。

zset跳表的数据结构⭐

增加了向前指针的链表叫作跳表跳表是一个随机化的数据结构,实质就是一种可以进行二分查找的有序链表。跳表在原有的有序链表上面增加了多级索引,通过索引来实现快速查找。跳表不仅能提高搜索性能,同时也可以提高插入和删除操作的性能。

原理:

跳表在原有的有序链表上面增加了多级索引,通过索引来实现快速查找。首先在最高级索引上查找最后一个小于当前查找元素的位置,然后再跳到次高级索引继续查找,直到跳到最底层为止,这时候以及十分接近要查找的元素的位置了(如果查找元素存在的话)。由于根据索引可以一次跳过多个元素,所以跳查找的查找速度也就变快了。

为什么使用跳跃表

首先,因为 zset 要支持随机的插入和删除,所以它 不宜使用数组来实现,关于排序问题,我们也很容易就想到 红黑树/ 平衡树 这样的树形结构,为什么 Redis 不使用这样一些结构呢?

  1. 性能考虑: 在高并发的情况下,树形结构需要执行一些类似于 rebalance 这样的可能涉及整棵树的操作,相对来说跳跃表的变化只涉及局部 (下面详细说)
  2. 实现考虑: 在复杂度与红黑树相同的情况下,跳跃表实现起来更简单,看起来也更加直观;

redis 设置过期时间

Redis中有个设置时间过期的功能,即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库,这是非常实用的。如我们一般项目中的 token 或者一些登录信息,尤其是短信验证码都是有时间限制的,按照传统的数据库处理方式,一般都是自己判断过期,这样无疑会严重影响项目性能。

我们 set key 的时候,都可以给一个 expire time,就是过期时间,通过过期时间我们可以指定这个 key 可以存活的时间。

如果假设你设置了一批 key 只能存活1个小时,那么接下来1小时后,redis是怎么对这批key进行删除的?

数据过期策略⭐

定期删除+惰性删除。

通过名字大概就能猜出这两个删除方式的意思了。

  • 定期删除:redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key,检查其是否过期,如果过期就删除。注意这里是随机抽取的。为什么要随机呢?你想一想假如 redis 存了几十万个 key ,每隔100ms就遍历所有的设置过期时间的 key 的话,就会给 CPU 带来很大的负载!
  • 惰性删除 :定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key,靠定期删除没有被删除掉,还停留在内存里,除非你的系统去查一下那个 key,才会被redis给删除掉。

但是仅仅通过设置过期时间还是有问题的。我们想一下:如果定期删除漏掉了很多过期 key,然后你也没及时去查,也就没走惰性删除,此时会怎么样?如果大量过期key堆积在内存里,导致redis内存块耗尽了。怎么解决这个问题呢? redis 内存淘汰机制。

数据淘汰机制⭐

当内存到达最大内存限制时进行的数据淘汰策略

  1. 新写入操作会报错。(Redis 默认策略)
  2. 在键空间中,移除最近最少使用的 Key。(LRU推荐使用)
  3. 在键空间中,随机移除某个 Key。
  4. 在设置了过期时间的键空间中,移除最近最少使用的 Key。这种情况一般是把 Redis 既当缓存,又做持久化存储的时候才用。
  5. 在设置了过期时间的键空间中,随机移除某个 Key。
  6. 在设置了过期时间的键空间中,有更早过期时间的 Key 优先移除。

LRU 算法实现:1.通过双向链表来实现,新数据插入到链表头部;2.每当缓存命中(即缓存
数据被访问),则将数据移到链表头部;3.当链表满的时候,将链表尾部的数据丢弃。
LinkedHashMap:HashMap 和双向链表合二为一即是 LinkedHashMap。HashMap 是无序
的,LinkedHashMap 通过维护一个额外的双向链表保证了迭代顺序。该迭代顺序可以是插
入顺序(默认),也可以是访问顺序。

Redis的LRU具体实现:

传统的LRU是使用栈的形式,每次都将最新使用的移入栈顶,但是用栈的形式会导致执行select *的时候大量非热点数据占领头部数据,所以需要改进。Redis每次按key获取一个值的时候,都会更新value中的lru字段为当前秒级别的时间戳。Redis初始的实现算法很简单,随机从dict中取出五个key,淘汰一个lru字段值最小的。在3.0的时候,又改进了一版算法,首先第一次随机选取的key都会放入一个pool中(pool的大小为16),pool中的key是按lru大小顺序排列的。接下来每次随机选取的keylru值必须小于pool中最小的lru才会继续放入,直到将pool放满。放满之后,每次如果有新的key需要放入,需要将pool中lru最大的一个key取出。淘汰的时候,直接从pool中选取一个lru最小的值然后将其淘汰。

Redis 持久化的两种方式⭐

  • RDB:快照形式是直接把内存中的数据保存到一个dump的文件中,定时保存,保存策略。 当Redis需要做持久化时,Redis会fork一个子进程,子进程将数据写到磁盘上一个临时RDB文件中。当子进程完成写临时文件后,将原来的RDB替换掉。
  • AOF:把所有的对Redis的服务器进行修改的命令都存到一个文件里,命令的集合。 使用AOF做持久化,每一个写命令都通过write函数追加到appendonly.aof中。aof的默认策略是每秒钟fsync一次,在这种配置下,就算发生故障停机,也最多丢失一秒钟的数据。 缺点是对于相同的数据集来说,AOF的文件体积通常要大于RDB文件的体积。根据所使用的fsync策略,AOF的速度可能会慢于RDB。对于主从同步来说,主从刚刚连接的时候,进行全量同步(RDB);全同步结束后,进行增量同步(AOF)。

如果同时使用 RDB 和 AOF 两种持久化机制,那么在 redis 重启的时候,会使用 AOF 来重新构建数据,因为 AOF 中的数据更加完整

RDB 持久化优点
RDB是一个紧凑压缩的二进制文件,存储效率高
RDB恢复数据速度比AOF快

RDB持久化缺点
无法做到实时持久化,具有较大可能丢失数据
存储数量较大时,效率较低,I/O性能较低
基于fork创建子进程,内存产生额外消耗
宕机带来的数据丢失风险

AOF 优点

  • AOF 可以更好的保护 数据不丢失,一般 AOF 会每隔 1 秒,最多丢失 1 秒钟的数据。
  • 写入性能非常高,而且文件不容易破损
  • 适合做灾难性的误删除的紧急恢复

AOF 缺点

对于同一份数据来说,AOF 日志文件通常比 RDB 数据快照文件更大。

恢复速度较慢

RDB 与 AOF 如何选择

对数据非常敏感,建议使用默认的AOF持久化方案
AOF策略使用everysec,每秒fsync一次,该策略仍可保持很好性能,出现问题最多丢失一秒内的数据
数据可以做到阶段内无丢失,且恢复较快,阶段点数据恢复通常使用RDB方案

综合:
如果不能承受分钟内的数据丢失,对业务数据非常敏感,选用AOF
如果能承受分钟内的数据丢失,且追求大数据集的恢复速度选用RDB,RDB 非常适合灾难恢复。
双保险策略,同时开启RDB和AOF,重启后Redis优先使用AOF来恢复数据,降低丢失数据量

为什么要用缓存?

用缓存,主要有两个用途:高性能高并发

怎么保证缓存和数据库数据的一致性?⭐

分布式环境下非常容易出现缓存和数据库间数据一致性问题,针对这一点,如果项目对缓存的要求是强一致性的,那么就不要使用缓存。

我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率,而无法保证两者间的强一致性。

  • 合理设置缓存的过期时间。
  • 新增、更改、删除数据库操作时同步更新 Redis,可以使用事务机制来保证数据的一致性。
  • 缓存失败时增加重试机制。

redis 怎么实现分布式锁?

Redis 分布式锁其实就是在系统里面占一个“坑”,其他程序也要占“坑”的时候,占用成功了就可以继续执行,失败了就只能放弃或稍后重试。

占坑一般使用 setnx(set if not exists)指令,只允许被一个程序占有,使用完调用 del 释放锁

也可以配合EXPIRE key seconds自动释放锁
设置key的生存时间,当key过期时(生存时间为0) ,会被自动删除
风险/ 缺陷 :原子性没有得到满足,所以不建议。

缓存雪崩

在一个较短的时间内,缓存中较多的key集中过期或者缓存挂了,导致了数据库服务器崩溃

缓存雪崩的事前事中事后的解决方案如下:

在批量往Redis存数据的时候,把每个Key的失效时间都加个随机值就好了,这样可以保证数据不会再同一时间大面积失效。如果 Redis 是集群部署,将热点数据均匀分布在不同的 Redis 库中也能避免全部失效。或者设置热点数据永不过期,有更新操作就更新缓存就好了

缓存穿透

原因:

  1. Redis中大面积出现未命中
  2. 出现非正常URL访问

解决方案:最简单粗暴的方法如果一个查询返回的数据为空(不管是数据不存在,还是系统故障),我们就把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。

**布隆过滤器(Bloom Filter)**这个也能很好的预防缓存穿透的发生,就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在,不存在你return就好了,存在你就去查DB刷新KV再return

缓存击穿

缓存击穿是指一个Key非常热点,在不停地扛着大量的请求,大并发集中对这一个点进行访问,当这个Key在失效的瞬间,持续的大并发直接落到了数据库上,就在这个Key的点上击穿了缓存。

解决:设置热点数据永不过期,或者加上个锁就搞定了。

假如 Redis 里面有 1 亿个 key ,其中有 10w 个 个 key 是以某个固定的已知的前缀开头的,如
果将它们全部找出来?
使用 keys 指令可以扫出指定模式的 key 列表。
对方接着追问:如果这个 redis 正在给线上的业务提供服务,那使用 keys 指令会有什么问
题?
这个时候你要回答 redis 关键的一个特性:redis 的单线程的。keys 指令会导致线程阻塞一
段时间,线上服务会停顿,直到指令执行完毕,服务才能恢复。这个时候可以使用 scan 指
令,scan 指令可以无阻塞的提取出指定模式的 key 列表,但是会有一定的重复概率,在客
户端做一次去重就可以了,但是整体所花费的时间会比直接用 keys 指令长。

实际项目中使用缓存有遇到什么问题或者会遇到什么问题你知道吗?

缓存和数据库数据一致性问题

主从复制

作用:
读写分离:master写、slave读,提高服务器的读写负载能力
负载均衡:基于主从结构,配合读写分离,由slave分担master负载,并根据需求的变化,改变slave的数量,通过多个从节点分担数据读取负载,大大提高Redis服务器并发量与数据吞吐量
故障恢复:当master出现问题时,由slave提供服务,实现快速的故障恢复
数据冗余:实现数据热备份,是持久化之外的一种数据冗余方式
高可用基石:基于主从复制,构建哨兵模式与集群,实现Redis的高可用方案

过程:

  • 从节点执行 slaveof IP,port 发送指令
  • 主节点响应
  • 从节点保存主节点信息(IP,port),建立和主节点的 Socket 连接。
  • 从节点发送 Ping 信号,主节点返回 Pong,确定两边能互相通信。
  • 连接建立后,主节点将所有数据发送给从节点(数据同步)。
  • 主节点把当前的数据同步给从节点后,便完成了复制的建立过程。接下来,主节点就会持续的把写命令发送给从节点,保证主从数据一致性。

复制/数据同步过程分为两个阶段

  1. 全量复制:
    slave接收到master生成的RDB文件,先清空自身的旧数据,然后执行RDB恢复过程,然后告知master已经恢复完毕。
  2. 部分复制(增量复制)
    主节点发送数据给从节点过程中,主节点还会进行一些写操作,这时候的数据存储在复制缓冲区中。master把自己之前创建的复制缓冲区的数据发送到slave,slave接收到aof指令后执行重写操作,恢复数据。

主从复制会存在以下问题:

  • 一旦主节点宕机,从节点晋升为主节点,同时需要修改应用方的主节点地址,还需要命令所有从节点去复制新的主节点,整个过程需要人工干预。
  • 主节点的写能力受到单机的限制。
  • 主节点的存储能力受到单机的限制。

哨兵:

哨兵(sentinel) 是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

作用:

监控
不断的检查master和slave是否正常运行。
master存活检测、master与slave运行情况检测

通知(提醒)
当被监控的服务器出现问题时,向其他(哨兵间,客户端)发送通知。

自动故障转移
断开master与slave连接,选取一个slave作为master,将其他slave连接到新的master,并告知客户端新的服务器地址