【java面试】redis篇

一、适用场景

问：你在项目中，都用到了redis,你在最近的哪些场景中使用了redis？
答：（结合实际项目情况）

（一）缓存

查询流程：

请求路径：
一个get请求：api/new/getById/1

1、缓存穿透

描述：查询一个不存在的数据，mysal查询不到数据写不会直接写入缓存，导致每次请求都查数据库

1.1 解决方案1：缓存空数据，查询返回的数据为空，将空结果缓存

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

{key:1,value:null}

1.2 解决方案2：布隆过滤器

bitmap（位图）：相当于以位（bit） 为单位的数组，数组中每个单元只能存储二进制数0或1
布隆过滤器作用：可以用于检索一个元素是否存在一个集合中
实现方案：Redission、Guava

但是布隆过滤器会出现误判，情况如下：

误判率：数组越小误判率就越大，数组越大误判率就越小，但是消耗内存更多。一般情况下设置在百分之五以内。

2、缓存击穿

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

1.1 解决方案1：互斥锁

1.2 解决方案2：逻辑过期

高热点key不设置过期时间，但是存储数据中有一个"expire"过期字段，当该字段为0时，说明数据过期，但是该数据仍旧存在（也就是高热点key不过期）。来查询该字段的线程会：
①获取互斥锁（用于保证重建缓存数据的互斥性）
②新开线程（用于重建缓存数据）
③在原有的线程上，返回过期数据
④如果正在重建缓存的基础上有新线程查询到数据，那么将会获取互斥锁失败，（不做等待）也直接返回过期数据。
⑤重建完成后，有新线程查询，将命中更新后的的新数据

更新前后返回数据可能不一致，但是不会等待，高可用，更加注重用户体验。

3、缓存雪崩

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

3.1 大量key过期

解决方案：给不同的key的TTl添加随机值

3.2 Redis服务宕机

解决方案：利用Redis集群提高服务的可用性（哨兵模式、集群模式）

3.3 给缓存业务添加降级限流策略（通用）

解决描述：ngxin或spring cloud gateway
降级可作为系统的保底策略，适用于穿透、击穿、雪崩

3.4 给业务添加多级缓存

解决描述：Guava或Caffeine

4、双写一致性

问：redis作为缓存，mysql的数据如何与redis进行同步？
答：（一定设置前提）先介绍自己的业务背景

4.1 双写一致（一致性要求高）

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

• 读操作：缓存命中，直接返回；缓存未命中，查询数据库，写入缓存，设定超时时间。
• 写操作：延时双删
  

普通删除操作仅有：
无论是先删除缓存还是先删除数据库都会出现问题——脏数据。

①先删除缓存，再删除数据库
正常情况：

异常情况：

②先删除数据库，再删除缓存
正常情况：

异常情况（查询时Redis已过期自动删除了：null）：

删除两次缓存为了减少上面两种情况的脏数据
延时删除：数据库时主从同步，延时给数据库同步的时间

4.1 分布式锁

效率较低。

4.2 读写锁

4.2 允许短暂的不一致

①异步通知：保证数据的最终一致性

②基于Canal的异步通知
不需要修改业务代码，伪装为mysql的一个从节点，canal通过读取binlog数据更新缓存.

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

5、持久化

问：redis作为缓存，数据持久化是怎么做的？
在Redis中提供了两种数据持久化的方式：RDB、AOF

5.1 RDB

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

②自动备份：redis内部有触发RDB的机制，可以在Redis.conf文件中找到，格式如下：
RDB执行原理：
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。
完成fork后读取内存数据并写入RDB文件。
fork采用的是copy-on-write技术:

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

5.2 AOF

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

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

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


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

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

5.3 RDB和AOF对比

二者各有优缺点，如果对数据安全性要求较高，在实际开发中往往结合两者来使用：

回答：

6、数据过期策略

问：redis的key过期后，会立马删除吗？
redis对数据设置数据的有效时间，数据过期以后，就需要将数据从内存中删除掉。可以按照不同的规则进行删除，这种删除规则就是数据的删除策略（数据过期策略）。有惰性删除和定期删除两种

6.1 惰性删除

设置该key过期时间后，我们不去管它，当需要该key时，我们检查它是否过期，如果过期我们就删除，反之，没过期就返回。

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

6.2 定期删除

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

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

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

Redis的过期删除策略：惰性删除 + 定期删除 配合使用

7、数据淘汰策略

问：假如缓存过多，内存是有限的，内存被占满了怎么办？

适用建议：

（二）分布式锁

问：redis分布式锁，如何实现？
集群情况下的定时任务、抢单、幂等性场景。

1、场景描述

eg:抢券

正常流程：

错误流程：

解决办法：加锁（单体项目）

多体项目（分布式锁）：

2、redis实现分布式锁

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


设置锁的过期时间：
①根据业务时间预估
②给过期时间预估——Redission实现的分布式锁

加锁、设置过期时间等操作都是基于lua脚本完成——保证执行的原子性

3、Redission实现的分布式锁可重入

在同一线程的基础上：
①执行add1（）创建"heimalock",同时value设置为1
②调用add2（），value加1
③add2（）执行结束，value减1
④add1（）执行结束，value减1，此时value变为0，删除"heimalock"

4、Redission实现的分布式锁——主从一致性——红锁

主节点负责写操作，从节点负责对外的读操作

当主节点宕机后，从从节点中选择一个当主节点，但此时主节点的信息还没同步过来，就会出现两个线程持有同一把锁的情况：

AP思想：优先保证高可用性
CP思想：保证数据的强一致性
了解AP和CP思想：https://blog.csdn.net/weixin_43475992/article/details/136280242

5、总结

二、其他面试题

问：redis集群有哪些方案？

（一）主从复制、主从同步

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

1、主从同步流程——全量同步

Replication ld:简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的replid
offset:偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset,如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

2、主从同步流程——增量同步（slave重启或者后期数据变化）

3、总结

（二）哨兵模式、集群脑裂

1、哨兵模式

主从模式保证不了集群的高可用，主节点宕机之后，就丧失了写数据的能力。Redis提供了哨兵（Sentinel)机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下:

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

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

2、集群脑裂

由于网络断裂的原因，一个高可用集群中，实际上分裂为多个小的集群，这种情况就称为裂脑。也有的人称之为分区集群，或者大脑垂直分隔，互相接管对方的资源，出现多个Master的情况，都可以称为脑裂。


redis中有两个配置参数:
min-replicas-to-write 1表示最少的salve节点为1个
min-replicas-max-lag 5表示数据复制和同步的延迟不能超过5秒

3、总结

（三）分片集群、数据读取

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

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

使用分片集群可以解决上述问题，分片集群特征:

• 集群中有多个master，每个master保存不同数据。
• 每个master都可以有多个slave节点
• master之间通过ping监测彼此健康状态
• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

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

总结：

（四） 其他

1、Redis是单线程的，但为什么还是那么快？

2、用户空间和内核空间

Linux系统中一个进程使用的内存情况划分两部分:内核空间、用户空间
用户空间只能执行受限的命令(Ring3)，而且不能直接调用系统资源必须通过内核提供的接口来访问
内核空间可以执行特权命令(Ring0)，调用一切系统资源
Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区:
写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区
为了提高IO的效率：①减少无效的等待②较少内核空间和用户空间之间数据的拷贝

3、IO模型

3.1 阻塞I/O

3.2 非阻塞I/O

3.3 I/O多路复用

4、redis的网络模型

4.1 单线程模型

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

在这种单线程的模式下影响性能的永远是I/O

4.2 多线程模型

5、总结