Redis面试经验

Redis面经总结

回答以下问题进行自测：

redis常用数据类型？

redis常用数据类型包括：string、hash、list、set、zset，特殊数据类型有：geospatial、Hyperloglog 、Bitmaps 。

geospatial可以用于记录推算两地距离，其实底层就是zset，Hyperloglog 基数（不重复元素），优点：占用的内存是固定，2^64 不同的元素的技术，只需要占用 12KB内存。缺点：高并发有一定错误率，如果不能接受错误率（0.81%）就用set，不过这个用于纪律访问量的话，错误完全可以忽略不计。使用这个主要是为了计数访问量，而非保存用户数据。Bitmaps 位图。统计用户信息，活跃，不活跃！登录、未登录！统计两个状态的，都可以使用 Bitmaps。

有关hash底层：https://www.cnblogs.com/reecelin/p/13362104.html

zset底层是什么？好处是啥？

详情查看：https://blog.csdn.net/weichi7549/article/details/107335133/

有序集合对象的编码可以是ziplist或者skiplist。同时满足以下条件时使用ziplist编码：

• 元素数量小于128个
• 所有member的长度都小于64字节
• 不能满足上面两个条件的使用 skiplist 编码。以上两个条件也可以通过Redis配置文件zset-max-ziplist-entries 选项和 zset-max-ziplist-value 进行修改

• ziplist 编码的 Zset 使用紧挨在一起的压缩列表节点来保存，第一个节点保存 member，第二个保存 score。ziplist 内的集合元素按 score 从小到大排序，其实质是一个双向链表。虽然元素是按 score 有序排序的， 但对 ziplist 的节点指针只能线性地移动，所以在 REDIS_ENCODING_ZIPLIST 编码的 Zset 中， 查找某个给定元素的复杂度为 O(N)。
• skiplist 编码的 Zset 底层为一个被称为 zset 的结构体，这个结构体中包含一个字典和一个跳跃表。跳跃表按 score 从小到大保存所有集合元素，查找时间复杂度为平均 *O(logN)，最坏 O(N) 。*字典则保存着从 member 到 score 的映射，这样就可以用 O(1)的复杂度来查找 member 对应的 score 值。虽然同时使用两种结构，但它们会通过指针来共享相同元素的 member 和 score，因此不会浪费额外的内存。
• 好处：因为有序集合经常会进行 ZRANGE 或 ZREVRANGE 这样的范围查找操作，跳表里面的双向链表可以十分方便地进行这类操作。同时实现简单，比平衡树更简单。

为什么要用redis，它的好处在哪？

缓存分为本地缓存和分布式缓存。以 Java 为例，使⽤⾃带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，⽣命周期随着 jvm 的销毁⽽结束，并且在多实例的情况下，每个实例都 需要各⾃保存⼀份缓存，缓存不具有⼀致性。

1. redis支持丰富的数据类型，可以应对多种复杂场景。

2. redis可以将缓存数据持久化下来，解决一旦断电或者宕机，内存数据库中的数据将会全部丢失的问题。

3. 支持集群模式， redis ⽬前是原⽣⽀持 cluster 模式的。

4. Redis使⽤单线程的多路 IO 复⽤模型。（Redis 的性能瓶颈不再 CPU ，主要在内存和网络）（6.0版本使用了多线程）

   补充：Redis 支持多线程主要就是两个原因：

   • 可以充分利用服务器 CPU 资源，目前主线程只能利用一个核。
   • 多线程任务可以分摊 Redis 同步 IO 读写负荷。
   • Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行。

Redis事务介绍一下？

Redis 可以通过 MULTI，EXEC，DISCARD 和 WATCH 等命令来实现事务(transaction)功能。

> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
> EXEC
1) (integer) 1
2) (integer) 1Copy to clipboardErrorCopied

使用 MULTI命令后可以输入多个命令。Redis不会立即执行这些命令，而是将它们放到队列，当调用了EXEC命令将执行所有命令。

**Redis 是不支持 roll back 的，因而不满足原子性的（而且不满足持久性）。**注意redis单独一条指令是具有原子性的。

Redis官网也解释了自己为啥不支持回滚。简单来说就是Redis开发者们觉得没必要支持回滚，这样更简单便捷并且性能更好。Redis开发者觉得即使命令执行错误也应该在开发过程中就被发现而不是生产过程中。

Redis 内存淘汰机制了解么？

相关问题：MySQL 里有 2000w 数据，Redis 中只存 20w 的数据，如何保证 Redis 中的数据都是热点数据?

Redis 提供 6 种数据淘汰策略：

1. volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

4.0 版本后增加以下两种：

1. volatile-lfu（least frequently used）：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
2. allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key

删除分为：定期删除+惰性删除。 通过名字⼤概就能猜出这两个删除⽅式的意思了。

• 定期删除：redis默认是每隔 100ms 就随机抽取⼀些设置了过期时间的key，检查其是否过期， 如果过期就删除。注意这⾥是随机抽取的。为什么要随机呢？你想⼀想假如 redis 存了⼏⼗万 个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很⼤的负载！
• 惰性删除 ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删 除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存⾥，除⾮你的系统去查⼀下那 个 key，才会被redis给删除掉。这就是所谓的惰性删除，也是够懒的哈！

Redis持久化方式介绍一下，说一下二者特点？

Redis 支持两种形式的持久化，一种是RDB快照（snapshotting），另外一种是AOF（append-only-file）。

Redis 可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用。

快照持久化是 Redis 默认采用的持久化方式，在 Redis.conf 配置文件中默认有此下配置：

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。Copy to clipboardErrorCopied

AOF（append-only file）持久化

与快照持久化相比，AOF 持久化 的实时性更好，因此已成为主流的持久化方案。默认情况下 Redis 没有开启 AOF（append only file）方式的持久化，可以通过 appendonly 参数开启：

appendonly yesCopy to clipboardErrorCopied

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入硬盘中的 AOF 文件。AOF 文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的，默认的文件名是 appendonly.aof。

在 Redis 的配置文件中存在三种不同的 AOF 持久化方式，它们分别是：

appendfsync always    #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec  #每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no        #让操作系统决定何时进行同步Copy to clipboardErrorCopied

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec 选项 ，让 Redis 每秒同步一次 AOF 文件，Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

RDB优势和劣势

① 优势：

1. 方便大规模的数据恢复。RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
2. 速度快。生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

② 劣势:

1. 无法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，如果不采用压缩算法(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，影响性能。
2. 兼容问题。RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。
3. 数据存在丢失的可能。在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。

AOF的优势和劣势

① 优点：

1. 每一次修改都同步，文件的完整会更加好！
2. 每秒同步一次，可能会丢失一秒的数据
3. 从不同步，效率最高的！

② 缺点：

1. 相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢，故默认选择rdb持久化。

使用建议：

1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始
的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重
写，使得AOF文件的体积不至于过大。

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，也可以不使用任何持久化

4、同时开启两种持久化方式

• 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF
  文件保存的数据集要比RDB文件保存的数据集要完整。
• RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者
  建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有
  AOF可能潜在的Bug，留着作为一个万一的手段。

5、性能建议

• 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够
  了，只保留 save 900 1 这条规则。

• 如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自
  己的AOF文件就可以了。

  代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写也可以改到适当的数值。

• 如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本会比较两个 Master/Slave 中的 RDB文件，载入较新的那个。

补充：

AOF 重写可以产生一个新的 AOF 文件，这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。AOF 重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。

在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾，使得新旧两个 AOF 文件所保存的数据库状态一致。最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作

如何保证缓存和数据库数据的一致性？

可以采取以下几个方案：

1. 设置过期时间，让数据在一定时间内过期（不常用）

这样会导致在数据有效期内读取到脏数据，影响业务的正常执行。

2. 写入数据库前删除缓存，然后再写入数据库

这样也有有漏洞，假设A线程要写入数据库，那么会先删除缓存，此时B线程读取数据（A尚未写完）就会从数据库读取脏数据，最后A修改完数据库，但是缓存的数据因为B已经是脏数据了。

3. 针对②情况，先删除缓存，然后写数据库，再延时删除一次缓存。

首先删除缓存，然后写入数据库，哪怕这时候有业务读取错误数据也可以延迟（100ms）删除，防止影响后面的

4. 先更新数据库，再删缓存，如果删除失败可以将需要删除的key写入消息队列，再次读取出来知道删除成功。

主从复制了解吗？有什么用？主机宕机了，该如何处理？

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点
(master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。
Master以写为主，Slave 以读为主。

默认每一台都是主节点，一台机器可以有多个从节点，但是只能有一个主节点

实际使用中如果使用单机操作，性能会下降压力也很大，不如采用主从的方式降低压力

主从复制的作用主要包括：

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4. 高可用（集群）基石：主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

如果主机宕机了，可以采用哨兵模式处理

哨兵模式：自动选举主机的模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工
干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑
哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵） 架构来解决这个问题。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独
立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

1. 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
2. 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

过程描述

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

哨兵不仅仅监控redis服务器，还会相互监督

如果主机宕机了，选举出了新的主机。那么就算主机回来了，也只会成为新主机的从机

哨兵模式优点&缺点

优点：

1、哨兵集群，基于主从复制模式，实现主从配置的全部优点，即主从模式的升级版
2、主从可以切换，故障可以转移，系统的可用性就会更好（主要）

缺点：

1、Redis 集群容量一旦到达上限，在线扩容就十分麻烦（主要）
2、实现哨兵模式的配置较复杂，有很多细节

了解缓存穿透、击穿、雪崩吗？

缓存穿透

缓存穿透的概念很简单，当缓存与数据库中都不存在该数据时，由于当数据库查询不到数据就不会写入缓存，这个时候如果用户不断的恶意发起请求，就会导致这个不存在的数据每次请求都会查询DB，请求量大的情况下，就会导致DB压力过大，直接挂掉，这个现象称之为缓存穿透。

缓存穿透即在缓存中找不到数据，把请求都发往数据库，对存储层造成压力。

解决方式

1. 布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力；

• 原理：将所有可能存在数据，分别通过多个哈希函数生成多个哈希值，然后将这些哈希值存到一个足够大的**bitmap (特殊数据类型：位图)**中，此时一个一定不存在的数据就会被这个bitmap拦截，从而减少了数据库的查询压力。

布隆过滤器详解

布隆过滤器本身而言，根本没有存放完整的数据，只是运用一系列随机映射函数计算出位置，然后填充二进制向量。 但是有些数据算出来的映射值是一样的，就会造成误判，不过不存在的数据映射值为0是肯定的。

缓存击穿

缓存击穿 不等于 缓存穿透，而是指key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方式

1. 设置热点数据永不过期

从缓存层面来看，没有设置过期时间，所以不会出现热点 key 过期后产生的问题。

2. 加互斥锁

使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。 就是只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了 。

缓存雪崩

缓存雪崩，是指缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统带来很大压力。雪崩和击穿的区别在于，雪崩是多个key都找不到，而击穿是针对单个key而言。

产生雪崩的原因之一，假设缓存一个小时。那么当过了一个小时之时，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

当然也存在物理原因，比如一瞬间服务器都断电了。

解决方式

• 加锁排队

这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对
某个key只允许一个线程查询数据和写缓存，其他线程等待。

**注意：**加锁排队的解决方式分布式环境的并发问题，有可能还要解决分布式锁的问题；线程还会被阻塞，用户体验很差！因此，在真正的高并发场景下很少使用！

• 数据预热

数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

• 设置随机值

可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

• 还有限流，设置多级缓存等方案

什么是 RedLock？

Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫 Redlock，此种方式比原先的单节点的方法更安全。它可以保证以下特性：

1. 安全特性：互斥访问，即永远只有一个 client 能拿到锁
2. 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
3. 容错性：只要大部分 Redis 节点存活就可以正常提供服务

一般实际采用zookeeper作为分布式锁，在获取分布式锁的时候在locker节点下创建临时顺序节点，释放锁的时候删除该临时节点；

为啥RedisCluster设计成16384个槽？

参考：https://zhuanlan.zhihu.com/p/99037321

redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态。

• 采用哈希槽来实现，而不是一致性哈希。

redis总共有2^14个槽（即16384），在redis节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，在发送心跳包时使用bitmap压缩后是2k，也就是说使用2k的空间创建了16k的槽数。如果选择更大的数目会导致心跳包变大，且redis的集群主节点数量基本不可能超过1000个。

每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽。这种结构很容易添加或者删除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。

• 使用哈希槽的好处就在于可以方便的添加或移除节点。

追问：为什么不用一致性哈希（不知道一致性哈希：https://www.jianshu.com/p/49e3fbf41b9b）？

Redis的作者认为它的crc16(key) mod 16384的效果已经不错了，虽然没有一致性hash灵活，但实现很简单，节点增删时处理起来也很方便。

补充：对于槽位的转移和分派，Redis集群是不会自动进行的，而是需要人工配置的。所以Redis集群的高可用是依赖于节点的主从复制与主从间的自动故障转移。