Redis篇
Redis篇
场景
缓存穿透
缓存穿透：查询一个不存在的数据，mysql查询不到数据页不会直接写入缓存，就会导致每次请求都查询数据库。
解决方案一：缓存空数据，查询返回的数据为空，扔把这个空结果进行缓存
优点：简单
缺点：消耗内存，可能会发生不一致的问题
解决方案二：布隆过滤器
优点：内存占用较少，没有多余key
缺点：实现复杂，存在误判
缓存击穿
缓存击穿：给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮
解决方案一： 互斥锁
解决方案二： 逻辑过期
缓存雪崩
缓存雪崩：是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。
解决方案：
- 给不同的Key的TTL添加随机值
- 利用Redis集群提高服务的可用性 哨兵模式、集群模式
- 给缓存业务添加降级限流策略 Nginx、Spring Cloud Gateway
- 给业务添加多级缓存 Guava或Caffeine
注：降级可做为系统的保底策略，适用于穿透、击穿、雪崩
《缓存三兄弟》
穿透无中生有key，布隆过滤null隔离。
缓存击穿过期key， 锁与非期解难题。
雪崩大量过期key，过期时间要随机。
面试必考三兄弟，可用限流来保底。
双写一致性
redis做为缓存，mysql的数据如何与redis进行同步呢?
要根据自己业务背景进行回答：一种是一致性要求高，一种是允许延迟一致
双写一致性：当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致
读操作： 缓存命中，直接返回；缓存未命中查询数据库。写入缓存，设定超时时间
写操作： 延迟双删
1.先删除缓存，还是先修改数据库
答：无论怎么操作都会有脏数据产生。
2.为什么要删除两次缓存？
答：为了降低脏数据的产生
3.为什么要延迟删除？
答：一般情况下是主从模式 读写分离，要让主延迟一会同步到从数据库中，延迟的过程中 也会有脏数据的风险。
可以采用分布式锁
分布式锁： 绝对的保证数据的一致性但性能降低
放入缓存中的数据都是读多写少。
共享锁: 读锁readLock，加锁之后，其他线程可以共享读操作。
排他锁: 独占锁writeLock也叫，加锁之后，阻塞其他线程读写操作
这样就保证了强一致性，性能也会极大的提升。
代码实现：强一致，性能低
异步通知保证数据的最终一致性
基于Canal的异步通知：
1.介绍自己简历上的业务，我们当时是把文章的热点数据存入到了存中，虽然是热点数据，但是实时要求性并没有那么高，所以，我们当时采用的是异步的方案同步的数据
2.我们当时是把抢券的库存存入到了缓存中，这个需要实时的进行数据同步，为了保证数据的强一致我们当时采用的是redisson提供的读写锁来保证数据的同步
那你来介绍一下异步的方案(你来介绍一下redisson读写锁的这种方案)
允许延时一致的业务，采用异步通知
1.使用MQ中间中间件，更新数据之后，通知缓存删除
2.利用canal中间件，不需要修改业务代码，伪装为mysql的一个从节点，canal通过读取binlog数据更新缓存
强一致性的，采用Redisson提供的读写锁
1.共享锁: 读锁readLock，加锁之后，其他线程可以共享读操作2.排他锁:独占锁writeLock也叫，加锁之后，阻塞其他线程读写操作
Redis 持久化
redis做为缓存，数据的持久化是怎么做的？
在Redis提供了两种数据持久化的方式：1、RDB 2、AOF
RDB
RDB全称Redis Database Backup file (Redis数据备份文件)，也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据
Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：
900秒内，如果至少有1个key被修改，则执行bgsave
save 900 1
save 300 10
save 60 10000
RDB执行原理
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。
fork采用的事copy-on-write技术：
当主进程执行读操作时，访问共享内存
当主进程执行写操作时，则会拷贝一份数据，并执行写操作。
AOF
AOF全称为Append Only File (追加文件)。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。
AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF:
是否开启AOF功能，默认是no
appendonly yes
AOF文件的名称
appendfilename “appendonly.aof”
AOF的命令记录的频率也可以通过redis.conf文件来配:
表示每执行一次写命令，立即记录到AOF文件
appendfsvnc alwavs
写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsvnc evervsec
写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。
Redis 数据过期策略
假如Redis的key过期之后，会立即删除吗？
Redis对数据设置数据的有效时间，数据过期以后，就需要将数据从内存中删除掉。可以按照不同的规则进行
删除，这种删除规则就被称之为数据的删除策略 (数据过期策略)惰性删除，定期删除
Redis数据删除策略-惰性删除
惰性删除:设置该key过期时间店，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key
优点: 对CPU友好，只会在使用该key时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查
缺点: 对内存不友好，如果一个key已经过期，但是一直没有使用，那么该key就会一直存在内存中，内存永远不会释放
Redis数据删除策略-定期删除
定期删除:每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的过期key)。
定期清理有两种模式：
SLOW模式 是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf 的hz 选项来调整这个次数
FAST模式 执行频率不固定，每次耗时不超过1ms，但两次间隔不低于2ms
优点: 可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。
缺点: 难以确定删除操作执行的时长和频率
Redis的过期删除策略: 惰性删除 + 定期删除两种策略进行配合使用
假如缓存过多，内存是有限的，内存被占满了怎么办？
Redis 数据淘汰策略
数据的淘汰策略: 当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。
Redis支持8种不同策略来选择要删除的key：
noeviction: 不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略。
volatile-ttl: 对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰。
allkeys-random: 对全体key，随机进行淘汰。
volatile-random: 对设置了TTL的key ，随机进行淘汰。
LRU (Least Recently Used) 最近最少使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高
LFU (Least Frequently Used) 最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高
allkeys-lru: 对全体key，基于LRU算法进行淘汰
volatile-lru: 对设置了TTL的key，基于LRU算法进行淘汰
allkeys-lfu: 对全体key，基于LFU算法进行淘汰volatile-lfu: 对设置了TTL的key，基于LFU算法进行淘汰
数据淘汰策略-使用建议
1.优先使用 alkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷
热数据区分，建议使用。
2.如果业务中数据访问频率差别不大，没有明显冷热数据区分,建议使用 allkeys-random，随机选择淘汰。
3.如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除会淘汰其他设置过期时间的数据。
4.如果业务中有短时高频访问的数据，可以使用 allkeys-lfu 或 volatile-lfu 策略
关于数据淘汰策略其他的面试问题
1.数据库有1000万数据，Redis只能缓存20w数据，如何保证Redis中的数据都是热点数据？
使用allkeys-lru(挑选最近最少使用的数据淘汰)淘汰策略，留下来的都是经常访问的热点数据
2.Redis的内存用完了会发生什么？
主要看数据淘汰策略是什么?如果是默认的配置(noeviction )，会直接报错
Redis分布式锁，是如何实现的？
需要结合项目中的业务进行回答，通常情况下，分布式锁使用的场景:
集群情况下的定时任务、抢单、幂等性场景
抢卷场景
**Redis分布式锁**
Redis实现分布式锁主要利用Redis的setnx命令。setnx是SET if not exists(如果不存在，则SET)的简写。
获取锁：NX是互斥，EX是设置超时时间
SET lock value NX EX 10
释放锁：
DEL key
Redis实现分布式锁如何合理的控制锁的有效时长?
根据业务执行时间预估 给锁续期
redisson实现的分布锁–执行流程
redisson实现的分布锁–可重入
redisson实现的分布锁–主从一致性
RedLock(红锁): 不能只在一个redis实例上创建锁，应该是在多个redis实例上创建锁(n /2 + 1)，避免在一个redis实例上加锁。
总结：
redis分布式锁，是如何实现的?
先按照自己简历上的业务进行描述分布式锁使用的场景
我们当使用的redisson实现的分布式锁，底层是setnx和lua脚本(保证原子性)
Redisson实现分布式锁如何合理的控制锁的有效时长?
在redisson的分布式锁中，提供了一个WatchDog(看门狗)一个线程获取锁成功以后，WatchDog会给持有锁的线程续期 (默认是每隔10秒续期一次)
Redisson的这个锁，可以重入吗?
可以重入，多个锁重入需要判断是否是当前线程，在redis中进行存储的时候使用的hash结构来存储线程信息和重入的次数
Redisson锁能解决主从数据一致的问题吗
不能解决，但是可以使用redisson提供的红锁来解决，但是这样的话，性能就太低了，如果业务中非要保证数据的强一致性，建议采用zookeeper实现的分布式锁
其他面试题
Redis集群有哪些方案，知道么
在Redis中提供的集群方案总共有三种：
主从复制
哨兵模式
分片集群
1redis主从数据同步的流程是什么?
2怎么保证redis的高并发高可用?
3.你们使用red是单点还是集群，哪种集群?
4.Redis分片集群中数据是怎么存储和读取的?
5.Redis集群脑裂，该怎么解决呢?
主从复制
单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。
主从数据同步原理
主从全量同步：
Replication ld:简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的replid
offset: 偏移量，随着记录在repl baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。
如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。
主从增量同步(slave重启或后期数据变化)
总结：
介绍一下redis的主从同步
单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。般都是一主多从，主节点负责写数据，从节点负责读数据
能说一下，主从同步数据的流程
全量同步：
1.从节点请求主节点同步数据 (replication id、 offset )
2.主节点判断是否是第一次请求，是第一次就与从节点同步版本信息 (replication id和offset)
3.主节点执行bgsave，生成rdb文件后，发送给从节点去执行
4.在RDB生成执行期间，主节点会以命令的方式记录到缓冲区(一个日志文件)
5.把生成之后的命令日志文件发送给从节点进行同步
增量同步：
1.从节点请求主节点同步数据，主节点判断不是第一次请求，不是第一次就获取从节点的offset值
2.主节点从命令日志中获取offset值之后的数据，发送给从节点进行数据同步
哨兵的作用
Redis提供了哨兵 (Sentinel) 机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下
监控: Sentinel 会不断检查您的master和slave是否按预期工作
自动故障恢复: 如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
通知: Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端
服务状态监控
Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令:
主观下线: 如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
客观下线: 若超过指定数量(quorum)的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。
哨兵选主规则
首先判断主与从节点断开时间长短，如超过指定值就排该从节点
然后判断从节点的slave-priority值，越小优先级越高
如果slave-prority一样，则判断slave节点的offset值，越大优先级越高
最后是判断slave节点的运行id大小，越小优先级越高
redis集群(哨兵模式)脑裂
正常的主从架构：
总结
怎么保证Redis的高并发高可用：
哨兵模式:实现主从集群的自动故障恢复(监控、自动故障恢复、通知)
你们使用redis是单点还是集群，哪种集群
主从(1主1从)+哨兵就可以了。单节点不超过10G内存，如果Redis内存不足则可以给不同服务分配独立的Redis主从节点
redis集群脑裂，该怎么解决呢?
集群脑裂是由于主节点和从节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到主节点，所以通过选举的方式提升了一个从节点为主，这样就存在了两个master，就像大脑分裂了一样，这样会导致客户端还在老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将老的主节点降为从节点，这时再从新master同步数据，就会导致数据丢失
解决: 我们可以修改redis的配置，可以设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求
就可以避免大量的数据丢失
分片集群结构
主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：
使用分片集群可以解决上述问题，分片集群特征：
分片集群结构-数据读写
Redis分片集群引入了哈希槽的概念，Redis 集群有16384个哈希槽每个key通过CRC16 校验后对16384 取模来决定放置哪个槽，集群的每个节点负责一部分hash槽
总结：
redis的分片集群有什么作用：
Redis分片集群中数据是怎么存储和读取的?
Redis是单线程的，但是为什么还那么快
Redis是纯内存操作，执行速度非常快
采用单线程，避免不必要的上下文切换可竞争条件，多线程还要考虑线程安全问题
使用I/O多路复用模型，非阻塞IO
能解释一下I/O多路复用模型?
Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，I/O多路复用模型主要就是实现了高效的网络请求
用户空间和内核空间
常见的IO模型
阻塞IO (Blocking lO)
非阻塞I0(Nonblocking l0)
IO多路复用 (IO Multiplexing)
Redis网络模型
用户空间和内核空间
Linux系统中一个进程使用的内存情况划分两部分:内核空间、用户空间
用户空间 只能执行受限的命令(Ring3)，而且不能直接调用系统资源必须通过内核提供的接口来访问
内核空间 可以执行特权命令(Ring0)，调用一切系统资源
Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区:
写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备
读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区
阻塞IO
顾名思义，阻塞IO就是两个阶段都必须阻塞等待:
阶段一：
用户进程尝试读取数据(比如网卡数据)
此时数据尚未到达，内核需要等待数据
此时用户进程也处于阻塞状态
阶段二:
数据到达并拷贝到内核缓冲区，代表已就绪
将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据
可以看到，阻塞IO模型中，用户进程在两个阶段都是阻塞状态。
非阻塞IO
顾名思义，非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程：
阶段一：
用户进程尝试读取数据(比如网卡数据)
此时数据尚未到达，内核需要等待数据
返回异常给用户进程
用户进程拿到error后，再次尝试读取
循环往复，直到数据就绪
阶段二:
将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据
可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增！
IO多路复用
IO多路复用：是利用单个线程来同时监听多个Socket，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。
阶段一：
用户进程调用select，指定要监听的Socket集合
内核监听对应的多个socket
任意一个或多个socket数据就绪则返回readable
此过程中用户进程阻塞
阶段二：
用户进程找到就绪的socket
依次调用recvfrom读取数据
内核将数据拷贝到用户空间
用户进程处理数据
不过监听Socket的方式、通知的方式又有多种实现，常见的有：
select
poll
epoll
差异
select和poll只会通知用户进程有Socket就绪，但不确定具体是哪个Socket，需要用户进程逐个遍历Socket来确认
epoll则会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间
Redis网络模型
Redis通过IO多路复用来提高网络性能，并且支持各种不同的多路复用实现，并且将这些实现进行封装，提供了统一的高性能事件库
总结
能解释一下I/O多路复用模型?
- I/O多路复用
是指利用单个线程来同时监听多个Socket，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。目前的I/O多路复用都是采用的epoll模式实现，它会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间，不需要挨个遍历Socket来判断是否就绪，提升了性能。 - Redis网络模型
就是使用I/O多路复用结合事件的处理器来应对多个Socket请求
连接应答处理器
命令回复处理器，在Redis6.0之后，为了提升更好的性能，使用了多线程来处理回复事件
命令请求处理器，在Redis6.0之后，将命令的转换使用了多线程，增加命令转换速度，在命令执行的时候，依然是单线程