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，并告知客户端新的服务器地址