一文总结Redis面试知识点

淡淡的烟草味﹌ 2024-03-22 14:45 78阅读 0赞

#### 文章目录 ####

*   *  Redis知识点
     *   *  知识点1 缓存穿透
         *  知识点2 布隆过滤器
         *  知识点3 缓存击穿
         *  知识点4 缓存雪崩
         *  知识点4 双写一致性
         *  知识点5 Redis持久化
         *  知识点6 数据过期策略
         *  知识点7 数据淘汰策略
         *  知识点8 分布式锁
         *  知识点9 主从复制
         *  知识点10 哨兵模式
         *  知识点11 分片集群
         *  知识点12 IO多路复用
     *  Redis问答
     *   *  1 什么是缓存穿透 ? 怎么解决 ?
         *  2 你能介绍一下布隆过滤器吗？
         *  3 什么是缓存击穿 ? 怎么解决?
         *  4 什么是缓存雪崩 ? 怎么解决 ?
         *  5 Redis做为缓存，MySQL的数据如何与Redis进行同步呢？（双写一致性）
         *  6 Redis做为缓存，数据的持久化是怎么做的？
         *  7 Redis的数据过期策略有哪些 ?
         *  8 Redis的数据淘汰策略有哪些 ?
         *  9 数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的数据都是热点数据 ?
         *  10 redis分布式锁，是如何实现的？
         *  11 Redisson实现分布式锁如何合理的控制锁的有效时长？
         *  12 Redisson的这个锁，可以重入吗？
         *  13 Redisson锁能解决主从数据一致的问题吗
         *  14 Redis集群有哪些方案, 知道嘛 ?
         *  15 那你来介绍一下主从同步
         *  16 能说一下，主从同步数据的流程
         *  17 怎么保证Redis的高并发高可用?
         *  18 你们使用redis是单点还是集群，哪种集群
         *  19 Redis集群脑裂, 该怎么解决呢?
         *  20 redis的分片集群有什么作用
         *  21 Redis分片集群中数据是怎么存储和读取的？
         *  22 Redis是单线程的,为什么还那么快
         *  23 能解释一下I/O多路复用模型？

[https://www.bilibili.com/video/BV1yT411H7YK][https_www.bilibili.com_video_BV1yT411H7YK] P6-P19

![image-20230509161003075][]

### Redis知识点 ###

![image-20230509161401942][]

这个问题需要结合项目回答, 之后会拓展到很多话题  
![image-20230509161514003][]

比如设计到缓存三兄弟, 就会做如下发问

![image-20230509161554880][]

#### 知识点1 缓存穿透 ####

假设你提供的服务遇到了一个Get请求, `api/news/getById/1`

![image-20230509161727005][]

这是一个根据id查询文章的接口, 做了缓存, 首先会在缓存中查询, 查询不到的话才会去数据库查询. 如果数据库也没有, 会导致无法建立缓存, 导致每次请求都会到数据库.

**缓存穿透**：查询一个不存在的数据，mysql查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库

解决方案一：缓存空数据，查询返回的数据为空，仍把这个空结果进行缓存

优点：简单  
缺点：消耗内存，可能会发生不一致的问题

解决方案二：布隆过滤器  
![image-20230509162620119][]

优点：内存占用较少，没有多余key  
缺点：实现复杂，存在误判

#### 知识点2 布隆过滤器 ####

布隆过滤器(Bloom Filter)是一种空间效率极高的概率型数据结构，可以用于判断一个元素是否存在于集合中。它通过多个哈希函数将输入映射到不同的位数组上，并在这些位数组中设置相应的位来表示元素是否存在。

布隆过滤器作用：布隆过滤器可以用于检索一个元素是否在一个集合中。

![image-20230509163334021][]

存储数据：id为1的数据，通过多个hash函数获取hash值，根据hash计算数组对应位置改为1  
查询数据：使用相同hash函数获取hash值，判断对应位置是否都为1

当然, 有可能存在误判, 什么是误判呢?

假设现在已经存了id为1和2的数据

![image-20230509163526265][]

这个时候来了id为3的数据, 经过三次哈希, 发现对应的位置上都有, 就可以认为id为3的数据已存在. 但是实际并不存在

关于这个误判率, 数组越小误判率就越大，数组越大误判率就越小，但是同时带来了更多的内存消耗。

由于布隆过滤器实现起来比较复杂, 所以基本都是用框架, 比如优秀的分布式锁Redisson.

#### 知识点3 缓存击穿 ####

缓存击穿：给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮

![image-20230509171630235][]

有俩个条件, 热点Key, 而且缓存重建时间较长

解决方案:

解决方案一：互斥锁

就是加锁, 不让一起访问, 具有强一致的特性, 但是性能差

![image-20230509171819468][]

解决方案二：逻辑过期

这个方案呢, 就是不设置TTL, 设置一个过期时间标识这个数据过期没

当查询缓存时发现这个数据过期了, 就开启一个独立线程去重建缓存

重建缓存时间段 来的请求都会得到过期数据

![image-20230509171927875][]

#### 知识点4 缓存雪崩 ####

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

![image-20230509173450267][]

![image-20230509173551005][]

#### 知识点4 双写一致性 ####

双写一致性: 当修改了数据库的数据, 也要同时更新缓存的数据, 缓存和数据库的数据要保持一致.

![image-20230509174937419][]

*  读操作: 缓存命中，直接返回; 缓存未命中查询数据库，写入缓存，设定超时时间
 *  写操作: 延迟双删

![image-20230509175106889][]

问题来了, 先删除缓存还是先删除数据库?

先删除缓存再操作数据库可能会出现数据不一致的现象.

![image-20230509175415550][]

先操作数据库, 再删除缓存也会有极低的概率出现问题

![image-20230509175253531][]

延迟双删比以上两种方案更加优秀

想要保证**强一致性**, 可以使用分布式锁, 性能上会差一点.

但是一般加入缓存的数据具有**读多写少**的特性

可以结合使用

共享锁：读锁readLock，加锁之后，其他线程可以共享读操作  
排他锁：独占锁writeLock也叫，加锁之后，阻塞其他线程读写操作

![image-20230509210706329][]

获得更好的性能

--------------------

大部分时候我们不需要数据的强一致性, 可以接受数据短暂的不一致

可以使用异步通知保证数据的最终一致性.

![image-20230509210931926][]

除了MQ还可以使用Canel实现异步通知

![image-20230509211023236][]

二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。

canal是基于mysql的主从同步来实现的. 当我们需要的表数据发生了变化, 可以在缓存服务获取变化之后的数据, 更新到缓存.

这种方式的好处是对业务代码零侵入.

#### 知识点5 Redis持久化 ####

![image-20230509214510309][]

**第一种 RDB**

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据

![image-20230509214537900][]

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

![image-20230509214557913][]

RDB的执行原理？

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。  
fork采用的是copy-on-write技术：

*  当主进程执行读操作时，访问共享内存；
 *  当主进程执行写操作时，则会拷贝一份数据，执行写操作。

![image-20230509214742778][]

**另一种:AOF**

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

![image-20230509215155446][]

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

![image-20230509215239700][]

AOF的命令记录的频率也可以通过redis.conf文件来配：

![image-20230509215248996][]

<table> 
 <thead> 
  <tr> 
   <th><strong>配置项</strong></th> 
   <th><strong>刷盘时机</strong></th> 
   <th><strong>优点</strong></th> 
   <th><strong>缺点</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Always</td> 
   <td>同步刷盘</td> 
   <td>可靠性高，几乎不丢数据</td> 
   <td>性能影响大</td> 
  </tr> 
  <tr> 
   <td>everysec</td> 
   <td>每秒刷盘</td> 
   <td>性能适中</td> 
   <td>最多丢失1秒数据</td> 
  </tr> 
  <tr> 
   <td>no</td> 
   <td>操作系统控制</td> 
   <td>性能最好</td> 
   <td>可靠性较差，可能丢失大量数据</td> 
  </tr> 
 </tbody> 
</table>

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

![image-20230509215439155][]

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

![image-20230509215731289][]

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th><strong>RDB</strong></th> 
   <th><strong>AOF</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>持久化方式</td> 
   <td>定时对整个内存做快照</td> 
   <td>记录每一次执行的命令</td> 
  </tr> 
  <tr> 
   <td>数据完整性</td> 
   <td>不完整，两次备份之间会丢失</td> 
   <td>相对完整，取决于刷盘策略</td> 
  </tr> 
  <tr> 
   <td>文件大小</td> 
   <td>会有压缩，文件体积小</td> 
   <td>记录命令，文件体积很大</td> 
  </tr> 
  <tr> 
   <td>宕机恢复速度</td> 
   <td>很快</td> 
   <td>慢</td> 
  </tr> 
  <tr> 
   <td>数据恢复优先级</td> 
   <td>低，因为数据完整性不如AOF</td> 
   <td>高，因为数据完整性更高</td> 
  </tr> 
  <tr> 
   <td>系统资源占用</td> 
   <td>高，大量CPU和内存消耗</td> 
   <td>低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源</td> 
  </tr> 
  <tr> 
   <td>使用场景</td> 
   <td>可以容忍数分钟的数据丢失，追求更快的启动速度</td> 
   <td>对数据安全性要求较高常见</td> 
  </tr> 
 </tbody> 
</table>

#### 知识点6 数据过期策略 ####

![image-20230509222015318][]

**惰性删除**：设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key

![image-20230509222055110][]

优点 ：对CPU友好，只会在使用该key时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查  
缺点 ：对内存不友好，如果一个key已经过期，但是一直没有使用，那么该key就会一直存在内存中，内存永远不会释放

**定期删除**：每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的过期key)。

定期清理有两种模式：  
SLOW模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf 的hz 选项来调整这个次数  
FAST模式执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms

优点：可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。  
缺点：难以确定删除操作执行的时长和频率。

Redis的过期删除策略：**惰性删除 + 定期删除两种策略进行配合使用**

#### 知识点7 数据淘汰策略 ####

![image-20230509222619780][]

数据的淘汰策略：当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。

Redis支持8种不同策略来选择要删除的key：

![image-20230509222828621][]

*  noeviction： 不淘汰任何key，但是内存满时不允许写入新数据，**默认**就是这种策略。
 *  volatile-ttl： 对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰
 *  allkeys-random：对全体key ，随机进行淘汰。
 *  volatile-random：对设置了TTL的key ，随机进行淘汰。
 *  allkeys-lru： 对全体key，基于LRU算法进行淘汰
 *  volatile-lru： 对设置了TTL的key，基于LRU算法进行淘汰
 *  allkeys-lfu： 对全体key，基于LFU算法进行淘汰
 *  volatile-lfu： 对设置了TTL的key，基于LFU算法进行淘汰

![image-20230509222842118][]

数据淘汰策略-**使用建议**

*  优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分，建议使用。
 *  如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用 allkeys-random，随机选择淘汰。
 *  如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。
 *  如果业务中有短时高频访问的数据，可以使用 allkeys-lfu 或 volatile-lfu 策略。

#### 知识点8 分布式锁 ####

![image-20230509224959354][]

在单机状态, 在抢券场景下, 需要对库存加锁, 防止超卖

而在服务集群部署的情况下

![image-20230509225141365][]

不同的Tomcat有不同的JVM, 这个时候就需要分布式锁了.

![image-20230509225237186][]

Redis实现分布式锁主要利用Redis的setnx命令。setnx是SET if not exists(如果不存在，则 SET)的简写。

获取锁：  
![image-20230509225300156][]  
释放锁：

![image-20230509225309612][]

但是单纯的SetNX还很不完善, 存在以下问题, 我们选择现成的方案 Redisson.

重入问题：重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。

不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。

超时释放: 我们在加锁时增加了过期时间，这样的我们可以防止死锁，但是如果卡顿的时间超长，虽然我们采用了lua表达式防止删锁的时候，误删别人的锁，但是毕竟没有锁住，有安全隐患。

主从一致性： 如果Redis提供了主从集群，当我们向集群写数据时，主机需要异步的将数据同步给从机，而万一在同步过去之前，主机宕机了，就会出现死锁问题。

![image-20230509230259623][]

redisson实现的分布式锁是可重入的, 利用hash结构记录线程id和重入次数

![image-20230509230413172][]

对于主从一致性, Redisson提供了RedLock(红锁)：不能只在一个redis实例上创建锁，应该是在多个redis实例上创建锁(n / 2 + 1)，避免在一个redis实例上加锁。

![image-20230509230503906][]

![image-20230510102649071][]

#### 知识点9 主从复制 ####

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

![image-20230510103453481][]

主从数据同步原理

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid

offset：偏移量，随着记录在repl\_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

主从全量同步：

![image-20230510103609943][]

主从增量同步(slave重启或后期数据变化)

![image-20230510103825637][]

#### 知识点10 哨兵模式 ####

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下：

监控：Sentinel 会不断检查您的master和slave是否按预期工作  
自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主  
通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

![image-20230510111845682][]

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：  
主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。  
客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

![image-20230510111936581][]

哨兵选主规则  
首先判断主与从节点断开时间长短，如超过指定值就排该从节点  
然后判断从节点的slave-priority值，越小优先级越高  
如果slave-prority一样，则判断slave节点的offset值，越大优先级越高  
最后是判断slave节点的运行id大小，越小优先级越高。

redis集群（哨兵模式）脑裂

Redis哨兵模式中的脑裂现象（Split-Brain）是指当集群中的主节点（Master）与其它节点（Slaves）失去联系后，哨兵节点（Sentinels）会自动选举一台从节点作为新的主节点。但有时候，当网络发生分区（Network partition）时，主节点与一部分从节点无法通信，而另一部分从节点可以与主节点正常通信。这种情况下，可能会出现两个分区各自选举出不同的主节点，导致出现多个主节点同时存在的情况，这就是脑裂现象。

脑裂现象会导致数据一致性和可用性的问题，因此需要一些机制来避免或者解决这种情况。Redis中可以通过设置quorum来保证只有超过一半的哨兵节点才能进行选举，从而避免脑裂现象的发生。此外，还可以通过增加哨兵节点数量来提高系统的健壮性。

![image-20230510112240467][]

#### 知识点11 分片集群 ####

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

*  海量数据存储问题
 *  高并发写的问题

使用分片集群可以解决上述问题，分片集群特征：  
集群中有多个master，每个master保存不同数据  
每个master都可以有多个slave节点  
master之间通过ping监测彼此健康状态  
客户端请求可以访问集群任意节点，最终都会被转发到正确节点

![image-20230510120332841][]

分片集群结构-数据读写

Redis 分片集群引入了哈希槽的概念，Redis 集群有 16384 个哈希槽，每个 key通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash 槽。

![image-20230510120356045][]

#### 知识点12 IO多路复用 ####

**用户空间和内核空间**

Linux系统中一个进程使用的内存情况划分两部分：内核空间、用户空间  
用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源  
必须通过内核提供的接口来访问  
内核空间可以执行特权命令（Ring0），调用一切系统资源

![image-20230510154743266][]

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：  
写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备  
读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

**阻塞IO**

![image-20230510154833164][]

顾名思义，阻塞IO就是两个阶段都必须阻塞等待：  
阶段一：  
用户进程尝试读取数据（比如网卡数据）  
此时数据尚未到达，内核需要等待数据  
此时用户进程也处于阻塞状态  
阶段二：  
数据到达并拷贝到内核缓冲区，代表已就绪  
将内核数据拷贝到用户缓冲区  
拷贝过程中，用户进程依然阻塞等待  
拷贝完成，用户进程解除阻塞，处理数据

可以看到，阻塞IO模型中，用户进程在两个阶段都是阻塞状态。

**非阻塞IO**

![image-20230510154927733][]

顾名思义，非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。  
阶段一：  
用户进程尝试读取数据（比如网卡数据）  
此时数据尚未到达，内核需要等待数据  
返回异常给用户进程  
用户进程拿到error后，再次尝试读取  
循环往复，直到数据就绪  
阶段二：  
将内核数据拷贝到用户缓冲区  
拷贝过程中，用户进程依然阻塞等待  
拷贝完成，用户进程解除阻塞，处理数据  
可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

**IO多路复用**

IO多路复用：是利用单个线程来同时监听多个Socket ，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

![image-20230510155039143][]

阶段一：  
用户进程调用select，指定要监听的Socket集合  
内核监听对应的多个socket  
任意一个或多个socket数据就绪则返回readable  
此过程中用户进程阻塞  
阶段二：  
用户进程找到就绪的socket  
依次调用recvfrom读取数据  
内核将数据拷贝到用户空间  
用户进程处理数据

IO多路复用是利用单个线程来同时监听多个Socket ，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。不过监听Socket的方式、通知的方式又有多种实现，常见的有：

*  select
 *  poll
 *  epoll

差异：  
select和poll只会通知用户进程有Socket就绪，但不确定具体是哪个Socket ，需要用户进程逐个遍历Socket来确认  
epoll则会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间

![image-20230510155133460][]

Redis通过IO多路复用来提高网络性能，并且支持各种不同的多路复用实现，并且将这些实现进行封装， 提供了统一的高性能事件库

![image-20230510155908343][]

### Redis问答 ###

#### 1 什么是缓存穿透 ? 怎么解决 ? ####

缓存穿透是指在请求数据时, 在缓存中查不到, 在数据库也查不到的现象.

由于数据库中没有数据, 所以无法建立缓存来缓解数据库压力.

导致这个请求每次都会查询数据库, 给数据库造成压力.

解决办法呢 一般有两种

第一种就是在缓存中缓存空值, 但是有可能会造成短期的数据不一致

第二种呢就是使用布隆过滤器, 当查询到数据不存在时直接返回, 缺点呢是实现起来比较复杂, 有一定的误判率

#### 2 你能介绍一下布隆过滤器吗？ ####

布隆过滤器主要是用来判断一个元素是不是在一个集合里边. 我们使用的是Redisson提供的布隆过滤器.

布隆过滤器的底层呢, 是一个比较大的数组, 里面存二进制的数据.

当来了一个数据, 就经过三次哈希, 将对应的三个位置数据置为1.

查找就是看它三次哈希完了那个位置上是不是都是1, 都是1就认为它在这里面

布隆过滤器会产生一定的误判, 这个误判率是可以设置的, 占用的存储空间越大误判率就越低.

#### 3 什么是缓存击穿 ? 怎么解决? ####

缓存击穿就是热点Key刚好过期了, 而他的重建缓存时间又比较长, 这个时候大量请求同时进入数据库, 可能会把数据库压垮

解决办法呢一般有两种

一种呢就是互斥锁, 只让一个线程拿到锁去重建缓存, 其他的线程等待. 这种方案能保证强一致性, 但是性能较差

另一种呢就是逻辑过期, 这个方案就是数据永不过期, 但是会有一个过期时间字段标识数据是否过期. 当查询缓存时发现这个数据过期了就开启一个独立线程去重建缓存, 重建期间所有请求拿到的都是过期数据. 这种方案具有高可用性, 但不保证数据的绝对一致.

#### 4 什么是缓存雪崩 ? 怎么解决 ? ####

缓存雪崩呢就是大量缓存同时过期, 导致大量请求同时到达数据库, 给数据库造成巨大压力. 这个也可能由Redis服务宕机导致

解决办法呢主要

第一针对缓存设置随机的TTL

第二呢搭建Redis的集群保障缓存服务的高可用

第三呢可以给业务加一个限流策略作为兜底

第四可以考虑搭建多级缓存

#### 5 Redis做为缓存，MySQL的数据如何与Redis进行同步呢？（双写一致性） ####

对于商铺查询缓存, 虽然是热点数据, 但是实时性要求并没有那么高.

我采用的是先更新数据库再删除缓存的方案. 在查询缓存未命中时, 查询数据库, 将数据库的结果写入缓存, 并设置超时时间.

--------------------

而对于优惠券这种数据, 我采用的是Redisson分布式锁来实现的.

#### 6 Redis做为缓存，数据的持久化是怎么做的？ ####

Redis提供了两种数据持久化方案, RDB和AOF

RDB (Redis Database Backup file)是数据库备份文件, 它是将Redis内存存储的数据写到磁盘上. 默认开启

AOF是Append Only File, 他保存了Redis的每一个写命令. 默认关闭

如果可以容忍数分钟的数据丢失, 追求更快地启动速度, 选择RDB;

如果对数据安全性要求较高, 可以选择AOF. 一般二者结合使用.

#### 7 Redis的数据过期策略有哪些 ? ####

Redis是惰性删除和定期删除两种策略结合使用滴

惰性删除是指Key过期了不管他, 访问到它发现他过期了就把他删掉

定期删除是指每隔一段时间就对一些Key做检查, 删除里面过期的Key. 分为Slow模式和Fast模式

#### 8 Redis的数据淘汰策略有哪些 ? ####

有八种数据淘汰策略. 默认是noeviction, 内存满了就不写入新数据, 也不淘汰任何Key, 直接报错.

其余策略大致分为LRU和LFU,

LRU是最近最少使用, LFU是最少频率使用.

#### 9 数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的数据都是热点数据 ? ####

可以使用 allkeys-lru （挑选最近最少使用的数据淘汰）淘汰策略，那留下来的都是经常访问的热点数据

#### 10 redis分布式锁，是如何实现的？ ####

可以基于Redis的setnx命令实现, set if not exists. 结合ex过期避免死锁

但是自己实现的通常会存在以下问题

重入问题 不可重试 超时释放 主从一致

Redisson则是比较成熟的解决方案

#### 11 Redisson实现分布式锁如何合理的控制锁的有效时长？ ####

Redisson可以对锁的超时时间和最大等待时间做设置,

当锁的一个业务没有完成的时候, 在Redisson中引入了一个看门狗机制, 就是每隔一段时间检查当前业务是否还持有锁, 如果持有就增加锁的持有时间.

也就是说，如果一个拿到锁的线程一直没有完成逻辑，那么看门狗会帮助线程不断的延长锁超时时间，锁不会因为超时而被释放。

#### 12 Redisson的这个锁，可以重入吗？ ####

可以重入，多个锁重入需要判断是否是当前线程，在redis中进行存储的时候使用的hash结构，来存储线程信息和重入的次数

#### 13 Redisson锁能解决主从数据一致的问题吗 ####

不能解决，但是可以使用redisson提供的红锁来解决，但是这样的话，性能就太低了，如果业务中非要保证数据的强一致性，建议采用zookeeper实现的分布式锁.

#### 14 Redis集群有哪些方案, 知道嘛 ? ####

在Redis中提供的集群方案总共有三种：主从复制、哨兵模式、Redis分片集群

#### 15 那你来介绍一下主从同步 ####

嗯，是这样的，单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，可以搭建主从集群，实现读写分离。一般都是一主多从，主节点负责写数据，从节点负责读数据，主节点写入数据之后，需要把数据同步到从节点中

#### 16 能说一下，主从同步数据的流程 ####

主从同步分为两个阶段, 全量同步和增量同步

全量同步大概有这么个步骤

1 从节点请求主节点同步数据(replication id, offset)

2 主节点判断从节点是不是第一次请求, 是第一次就与从节点同步版本信息

3 主节点执行bgsave, 生成rdb文件后, 发送给从节点

4 rdb生成期间, 主节点会把接收到的命令记录到缓冲区(一个日志文件)

5 把生成的命令日志文件发送给从节点进行同步

增量同步呢

从节点向主节点请求数据, 主节点发现不是第一次请求, 根据从节点的offset值将offset之后的数据发送给从节点进行同步

#### 17 怎么保证Redis的高并发高可用? ####

可以搭建主从集群实现读写分离,

再加上哨兵模式, 实现主从集群的自动故障恢复. 当指定数量以上的哨兵监测认为master节点主观下线了, 就会从slave节点中选举出新的master.

#### 18 你们使用redis是单点还是集群，哪种集群 ####

我们当时采用的是一主一从加哨兵.

#### 19 Redis集群脑裂, 该怎么解决呢? ####

这个在项目中很少见

关于脑裂我的理解是这样的, 他是由于网络原因导致哨兵认为主节点下线, 选举出了新的主节点, 但是实际上主节点并没有下线, 这样就存在了两个master, 就跟大脑分裂了一样

网络恢复后, 老的master会被降为slave, 从新的master中同步数据, 这样会导致老master中大量数据丢失

解决办法呢 一是增加哨兵节点, 二是配置正确的quorum,就是当足够多的哨兵认为其主观下线了才客观下线该master

#### 20 redis的分片集群有什么作用 ####

集群中有多个master可以保存不同数据, 可以存储海量数据, 实现高并发写

然后呢 每个master又可以有多个slave节点, 可以高并发读

master之间可以ping互相监测彼此健康状态

客户端可以访问集群任意结点, 最终都会被转发到正确节点.

#### 21 Redis分片集群中数据是怎么存储和读取的？ ####

Redis分片集群引入了哈希槽的概念, Redis集群有16384个哈希槽

将16384个哈希槽分配到不同的实例

读写数据是根据Key的有效部分计算哈希值, 对16384取余, 余数作为插槽, 寻找插槽所在的实例.

#### 22 Redis是单线程的,为什么还那么快 ####

Redis是纯内存操作, 执行速度很快

使用单线程, 可以避免不必要的上下文切换, 也不用考虑线程安全问题

使用IO多路复用模型

#### 23 能解释一下I/O多路复用模型？ ####

IO多路复用是指利用单个线程来监听多个Socket, 并在某个Socket可读或可写时得到通知, 从而避免无效的等待, 充分利用CPU资源

目前IO多路复用都是采用的epoll模式来实现的, 他会在通知用户进程Socket就绪的同时, 把已就绪的Socket写入用户空间, 不需要挨个遍历Socket来判断是否就绪, 提升了性能

Redis捏就是使用IO多路复用结合事件的处理器来应对多个Socket请求

分为连接应答处理器 - 命令回复处理器 - 命令请求处理器

在Redis6.0的时候, 使用了多线程来处理回复事件, 命令的转换也使用了多线程,

命令的执行仍然是单线程

[https_www.bilibili.com_video_BV1yT411H7YK]: https://www.bilibili.com/video/BV1yT411H7YK
[image-20230509161003075]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/91fd685892b2487c90941d3ab1b5ae14.png
[image-20230509161401942]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/f83b11d3012245869abf85d41735a1f7.png
[image-20230509161514003]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/682a9fa464764b46b8761edcd7c866b6.png
[image-20230509161554880]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/2fc57975d2954b158eab2b3f42d31aba.png
[image-20230509161727005]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/0139b41852c14da18a8e2372654418a3.png
[image-20230509162620119]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/ff9a1b24b6e143f89977438487614202.png
[image-20230509163334021]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/cd320ff44e1641e0bb19b8249453c071.png
[image-20230509163526265]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/4bed2b0f69ec4e86b1a1e547996466c9.png
[image-20230509171630235]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/68cd8b20d3d443b9ab5e4f1f03932cea.png
[image-20230509171819468]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/7a75641c201840c0815c539e7f698220.png
[image-20230509171927875]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/f24c1df5112f492aa509c7657467fdc1.png
[image-20230509173450267]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/73b2628472d54f01a72b0e54471900c1.png
[image-20230509173551005]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/55e588745b0a4883bcef9ac6989d4350.png
[image-20230509174937419]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/d13c9ecdff154e3391fae1de1ef08717.png
[image-20230509175106889]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/45b4e7f66c2249728d11fb6d431bd60a.png
[image-20230509175415550]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/82bf4e66bdcd4c9a965f054985feb83c.png
[image-20230509175253531]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/2c270d7d086649129ee746d50c5ad0ff.png
[image-20230509210706329]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/c0d83d411460420bbce981111432f24e.png
[image-20230509210931926]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/f678bab2c6f94c3997ed050b6cc9987b.png
[image-20230509211023236]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/13c9b31e86414f2dac4ed1095b0c2ca3.png
[image-20230509214510309]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/116f51e67210484aa6559e9720c692eb.png
[image-20230509214537900]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/e7c38a289b85482d8b5eea414bbc9578.png
[image-20230509214557913]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/be5ae4f4c4b64dd9968934f60abef4b0.png
[image-20230509214742778]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/17bd13f651af4d20ab4401ae2838c310.png
[image-20230509215155446]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/f9d6dd0b818d4ccf8646a828a709d5f3.png
[image-20230509215239700]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/a71af4513a8245b7aa1a877331d604ca.png
[image-20230509215248996]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/4e79373100394ff2ae4c2571c705e2fa.png
[image-20230509215439155]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/c7b451a53c4848fd8223021f2d0728d8.png
[image-20230509215731289]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/df8984155340428abe394a93d55f3dfc.png
[image-20230509222015318]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/838d73d3a8c048dbade5fd5ad8fae0b7.png
[image-20230509222055110]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/4cee9c1f23e0491db05e5a09bd20bd32.png
[image-20230509222619780]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/8b3fdad934db4da18800c47bb4d8fd2a.png
[image-20230509222828621]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/a64e57e089c74ce2becdf10384adf687.png
[image-20230509222842118]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/faa9cc7124904c29971ae54e6691096a.png
[image-20230509224959354]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/953fad692d2a49d680ea8bde9417cd49.png
[image-20230509225141365]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/4f863c0584a248879bca86216fc4335b.png
[image-20230509225237186]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/05623bc387bc4a68bfa3382f9e2a05ff.png
[image-20230509225300156]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/64e5263103fe45eda2577fe90777760c.png
[image-20230509225309612]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/e246f23205c24e418dace1ac82d450e2.png
[image-20230509230259623]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/c80b7d14a6714ecd9b789de638d06617.png
[image-20230509230413172]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/0e8414394fc74a6487d1c6c891b36016.png
[image-20230509230503906]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/3e45e76f0f254d889be4226cac109951.png
[image-20230510102649071]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/415833d9e6d14168bec4a2b56ea88ceb.png
[image-20230510103453481]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/ab12bffa28934786841a6900fde0f10a.png
[image-20230510103609943]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/569ac9c9003c457da4a1d66eded6a41d.png
[image-20230510103825637]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/7276c4b48bf8415b8d30e01462279c8d.png
[image-20230510111845682]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/a0f49aa6a0dc402b9229fe3f53e2553c.png
[image-20230510111936581]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/9d8816a31a4347369a3c868e3f98a844.png
[image-20230510112240467]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/59c50e4a5d474966bf7a90fe8a2e285d.png
[image-20230510120332841]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/777840f618644a63805c5aefaf5e1c4a.png
[image-20230510120356045]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/d9f3b365799944efb958f064665ee4d0.png
[image-20230510154743266]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/d0336cb4546b490f980869eee97224c1.png
[image-20230510154833164]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/c733ec1bffc74f4ab7117c2cd508f316.png
[image-20230510154927733]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/46b22f8d145c468897c95f886daf7b8b.png
[image-20230510155039143]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/95746f8a07a744e9b15cb3c782498ea7.png
[image-20230510155133460]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/6b703cd2b63b43fe9dfe24f2bf11d050.png
[image-20230510155908343]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/720f5b4b83844c9e9767923dd4281b53.png