Redis面试题

Redis概述

Redis，英文全称是Remote Dictionary Server（远程字典服务），是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

与MySQL数据库不同的是，Redis的数据是存在内存中的。它的读写速度非常快，每秒可以处理超过10万次读写操作。因此redis被广泛应用于缓存，另外，Redis也经常用来做分布式锁。除此之外，Redis支持事务、持久化、LUA 脚本、LRU 驱动事件、多种集群方案。

Redis存储类型及特殊类型

  • String（字符串）
  • Hash（哈希）
  • List（列表）
  • Set（集合）
  • zset（有序集合）

Redis 的三种特殊数据类型

  • Geo：Redis3.2推出的，地理位置定位，用于存储地理位置信息，并对存储的信息进行操作。
  • HyperLogLog：用来做基数统计算法的数据结构，如统计网站的UV。
  • Bitmaps ：用一个比特位来映射某个元素的状态，在Redis中，它的底层是基于字符串类型实现的，可以把bitmaps成作一个以比特位为单位的数组

缓存穿透及解决方案

  • 定义 ：客户端请求的数据不仅在缓存没有查到，而且数据库中也没有；导致每次的请求的数据都能打到数据库中去，进行的无效的查询，不仅穿过了redis层也穿mysql层

  • 场景 ：恶意的请求数据、根本就不存在的值uuid,(-1,woshilaji)恶意值等

  • 方案：

    •  1. 把恶意的数据用另一个redis存储起来，当请求在redis未命中时可以再查询下无缓存数据的key值，假如数据库中有新值增加，可能会带来判断误差，可以把恶意数据的key值设置的时间稍微短一些，根据实际的场景应用情况合理的设置缓存的失效时间

    •  2. 布隆过滤器

缓存击穿及解决方案

  • 定义 ：缓存击穿是指缓存中没有但数据库中有的数据(一般是值一个热点key缓存时间到期),这时由于并发用户特别多，同时读缓存没有数据，接着去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

  • 场景 ：当一个key失效时，同时有大量并发请求到数据库，造成还没来得及缓存数据，都去数据库中查询数据了

  • 方案：

    • 高并发的key时设置一个永不过期的key

    • 使用redis的互斥锁，注意增加锁的默认失效时防止释放锁失败导致不能重置key值

    • 接口限流 与熔断 ，降级 。重要的接口一定要做好限流策略，防止用户恶意刷接口，同时要降级准备，当接口中的某些 服务 不可用时候，进行熔断，失败快速返回机制。

缓存雪崩及解决方案

  • 定义 ：缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大，和缓存击穿不同的是， 缓存击穿是同一个key，缓存雪崩不同key同时过期，很多数据都查不到从而查数据库。

  • 场景 ：网页首页的基本数据信息，同一时间设置缓存，几乎同一时间失效。

  • 方案：

    • 可以把缓存数据的有效期进行随机化，防止出现同一时间大量数据过期现象发生。

    • 把一些数据可以设置永久不过期，当有改动时主动删除并且设置缓存数据

Redis 过期策略和内存淘汰策略

  1. Redis的过期策略

    • 定时过期

      每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即对key进行清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

    • 惰性过期

      只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

    • 定期过期

      每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
      expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。

Redis中同时使用了惰性过期和定期过期两种过期策略。

假设Redis当前存放30万个key，并且都设置了过期时间，如果你每隔100ms就去检查这全部的key，CPU负载会特别高，最后可能会挂掉。
因此，redis采取的是定期过期，每隔100ms就随机抽取一定数量的key来检查和删除的。
但是呢，最后可能会有很多已经过期的key没被删除。这时候，redis采用惰性删除。在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间并且已经过期了，此时就会删除。
但是呀，如果定期删除漏掉了很多过期的key，然后也没走惰性删除。就会有很多过期key积在内存内存，直接会导致内存爆的。或者有些时候，业务量大起来了，redis的key被大量使用，内存直接不够了，运维小哥哥也忘记加大内存了。难道redis直接这样挂掉？不会的！Redis用8种内存淘汰策略保护自己~。
  1. Redis 内存淘汰策略
    • volatile-lru：当内存不足以容纳新写入数据时，从设置了过期时间的key中使用LRU（最近最少使用）算法进行淘汰；
    • allkeys-lru：当内存不足以容纳新写入数据时，从所有key中使用LRU（最近最少使用）算法进行淘汰。
    • volatile-lfu：4.0版本新增，当内存不足以容纳新写入数据时，在过期的key中，使用LFU算法进行删除key。
    • allkeys-lfu：4.0版本新增，当内存不足以容纳新写入数据时，从所有key中使用LFU算法进行淘汰；
    • volatile-random：当内存不足以容纳新写入数据时，从设置了过期时间的key中，随机淘汰数据；。
    • allkeys-random：当内存不足以容纳新写入数据时，从所有key中随机淘汰数据。
    • volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰；
    • noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。

Redis的常用应用场景

  • 缓存
  • 排行榜
  • 计数器应用
  • 共享Session
  • 分布式锁
  • 社交网络
  • 消息队列
  • 位操作

  1. 缓存

    我们一提到redis，自然而然就想到缓存，国内外中大型的网站都离不开缓存。合理的利用缓存，比如缓存热点数据，不仅可以提升网站的访问速度，还可以降低数据库DB的压力。并且，Redis相比于memcached，还提供了丰富的数据结构，并且提供RDB和AOF等持久化机制，强的一批。

  2. 排行榜

    当今互联网应用，有各种各样的排行榜，如电商网站的月度销量排行榜、社交APP的礼物排行榜、小程序的投票排行榜等等。Redis提供的zset数据类型能够实现这些复杂的排行榜。

  3. 计数器应用

    各大网站、APP应用经常需要计数器的功能，如短视频的播放数、电商网站的浏览数。这些播放数、浏览数一般要求实时的，每一次播放和浏览都要做加1的操作，如果并发量很大对于传统关系型数据的性能是一种挑战。Redis天然支持计数功能而且计数的性能也非常好，可以说是计数器系统的重要选择。

  4. 共享Session

    如果一个分布式Web服务将用户的Session信息保存在各自服务器，用户刷新一次可能就需要重新登录了，这样显然有问题。实际上，可以使用Redis将用户的Session进行集中管理，每次用户更新或者查询登录信息都直接从Redis中集中获取

  5. 分布式锁

    几乎每个互联网公司中都使用了分布式部署，分布式服务下，就会遇到对同一个资源的并发访问的技术难题，如秒杀、下单减库存等场景。

    • 用synchronize或者reentrantlock本地锁肯定是不行的。
    • 如果是并发量不大话，使用数据库的悲观锁、乐观锁来实现没啥问题。
    • 但是在并发量高的场合中，利用数据库锁来控制资源的并发访问，会影响数据库的性能。
    • 实际上，可以用Redis的setnx来实现分布式的锁。

  6. 社交网络

    赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等是社交网站的必备功能，由于社交网站访问量通常比较大，而且传统的关系型数据不太适保存 这种类型的数据，Redis提供的数据结构可以相对比较容易地实现这些功能。

  7. 消息队列

    消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

  8. 位操作

    用于数据量上亿的场景下，例如几亿用户系统的签到，去重登录次数统计，某用户是否在线状态等等。腾讯10亿用户，要几个毫秒内查询到某个用户是否在线，能怎么做？千万别说给每个用户建立一个key，然后挨个记（你可以算一下需要的内存会很恐怖，而且这种类似的需求很多。这里要用到位操作——使用setbit、getbit、bitcount命令。原理是：redis内构建一个足够长的数组，每个数组元素只能是0和1两个值，然后这个数组的下标index用来表示用户id（必须是数字哈），那么很显然，这个几亿长的大数组就能通过下标和元素值（0和1）来构建一个记忆系统。

Redis 的持久化机制有哪些

一：RDB

  1. RDB，就是把内存数据以快照的形式保存到磁盘上。

    RDB持久化，是指在指定的时间间隔内，执行指定次数的写操作，将内存中的数据集快照写入磁盘中，它是Redis默认的持久化方式。执行完操作后，在指定目录下会生成一个dump.rdb文件，Redis 重启的时候，通过加载dump.rdb文件来恢复数据。RDB触发机制主要有以下几种：

    RDB触发机制手动触发save同步，会阻塞当前redis服务器
    手动触发bgsave异步，redis进程执行fork操作创建子线程
    自动触发save m nm秒内数据集存在n次修改时，自动触发bgsave

  2. RDB 的优点

    • 适合大规模的数据恢复场景，如备份，全量复制等

  3. RDB 的缺点

    • 没办法做到实时持久化/秒级持久化。
    • 新老版本存在RDB格式兼容问题

二：AOF

AOF（append only file） 持久化，采用日志的形式来记录每个写操作，追加到文件中，重启时再重新执行AOF文件中的命令来恢复数据。它主要解决数据持久化的实时性问题。默认是不开启的。

  1. AOF的工作流程如下：

    2

  2. AOF的优点

    数据的一致性和完整性更高

  3. AOF的缺点

    AOF记录的内容越多，文件越大，数据恢复变慢。

怎么实现Redis的高可用？

将数据库复制多个副本以部署在不同的服务器上，其中一台挂了也可以继续提供服务。

Redis 实现高可用有三种部署模式：主从模式，哨兵模式，集群

  1. 主从模式

  2. Sentinel哨兵模式

  • 哨兵模式就三个作用：

    • 发送命令，等待Redis服务器（包括主服务器和从服务器）返回监控其运行状态；
    • 哨兵监测到主节点宕机，会自动将从节点切换成主节点，然后通过发布订阅模式通知其他的从节点，修改配置文件，让它们切换主机；
    • 哨兵之间还会相互监控，从而达到高可用。

  • 哨兵的工作模式如下：

    1. 每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他Sentinel实例发送一个 PING命令。
    2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel标记为主观下线。
    3. 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
    4. 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线。
    5. 在一般情况下， 每个 Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
    6. 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
    7. 若没有足够数量的 Sentinel同意Master已经下线， Master的客观下线状态就会被移除；若Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

  • 故障切换的过程

    假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

  1. Cluster集群模式

    哨兵模式基于主从模式，实现读写分离，它还可以自动切换，系统可用性更高。但是它每个节点存储的数据是一样的，浪费内存，并且不好在线扩容。因此，Cluster集群应运而生，它在Redis3.0加入的，实现了Redis的分布式存储。对数据进行分片，也就是说每台Redis节点上存储不同的内容，来解决在线扩容的问题。并且，它也提供复制和故障转移的功能。

  • 故障转移

    主观下线：

    某个节点认为另一个节点不可用，即下线状态，这个状态并不是最终的故障判定，只能代表一个节点的意见，可能存在误判情况

    客观下线：

    指标记一个节点真正的下线，集群内多个节点都认为该节点不可用，从而达成共识的结果。如果是持有槽的主节点故障，需要为该节点进行故障转移。

  • 故障恢复

更多推荐

Redis面试题(2022最新版)