一、缓存

1.缓存穿透

查询一个不存在的数据，DB查不到数据，不会写入缓存，导致每次请求都查DB

解决方案一：缓存空数据

缓存空数据，查询返回的数据为空，仍把这个空结果进行缓存{key:1,value:null}

缺点：消耗内存，一旦数据库确实存在数据，就会造成缓存与数据库不一致的问题

解决方案二：布隆过滤器

先查询布隆过滤器，不存在直接返回；布隆过滤器存在，查redis。（缓存预热时，需要预热布隆过滤器）

bitmap(位图)：相当于是一个以(bit)位为单位的数组，数组中每个单元只能存储二进制数0或1

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

image.png

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

可能存在误判：

image.png

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

布隆过滤器实现方案

• Redisson
• Guava

可以设置误判率，一般设置为5% boomFilter.tryInit(size,0.05)

缺点：实现复杂，存在误判

2.缓存击穿

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

解决方案一：互斥锁

image.png

性能差，强一致

解决方案二：逻辑过期

不设置键的过期时间，把过期时间作为value中的一个属性（逻辑时间）存进去。

image.png

在线程2没成功把新数据写入缓存之前，其他线程从缓存中获取的都是已经逻辑过期的旧数据。

性能好，弱一致

3.缓存雪崩

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

解决方案：

• 给不同的Key的TTL添加随机值
• 利用Redis集群提高服务的可用性（哨兵，分片集群）
• 给缓存业务添加降级限流策略（ngxin或spring cloud gateway）
• 给业务添加多级缓存（Guava或Caffeine）

二、双写一致性

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

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

先删除缓存，再更新数据库：

先删除缓存，再更新数据库.png

此时缓存中写入的还是旧的数据，因为线程1还未更新数据库

先更新数据库，再删除缓存

先更新数据库，再删除缓存.png

此时缓存中写入的还是旧数据，线程2还未更新数据库

1.强一致

使用分布式锁

image.png

读多写少场景：

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

2.弱一致

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

image.png

基于Canal的异步通知，基于mysql的主从同步来实现的。
二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。

image.png

cannal没有侵入性，利用canal中间件，不需要修改业务代码，伪装为mysql的一个从节点，canal通过读取binlog数据更新缓存

三、持久化

1.RDB

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

• save：主进程执行RDB，会阻塞所有命令
• bgsave：开启子进程执行RDB，避免主进程受影响

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技术：

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

image.png

页表：记录虚拟地址与物理地址的映射关系

2.AOF

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

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

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

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

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

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

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

# AOF文件比上次文件 增长超过多少百分比则触发重写�
auto-aof-rewrite-percentage 100� # 之前1M，现在2M，触发重写
# AOF文件体积最小多大以上才触发重写 �
auto-aof-rewrite-min-size 64mb 

在实际开发中会结合两者来使用

四、Redis的过期策略

Redis对数据设置数据的有效时间，数据过期以后，就需要将数据从内存中删除掉。可以按照不同的规则进行删除，这种删除规则就被称之为数据的删除策略（数据过期策略）。

1.惰性删除

设置该key过期时间后，不去管它，当需要该key时，再检查其是否过期，如果过期，就删掉它，反之返回该key

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

2.定期删除

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

定期清理有两种模式：

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

优缺点：

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

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

五、Redis数据淘汰策略

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

1.8种不同数据淘汰策略

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

• 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算法进行淘汰

2.LRU和LFU

LRU（Least Recently Used）最近最少使用。
用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
key1是在3s之前访问的, key2是在9s之前访问的，删除的就是key2

LFU（Least Frequently Used）最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。
key1最近5s访问了4次, key2最近5s访问了9次， 删除的就是key1

3.数据淘汰策略-使用建议

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

Q：数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的数据都是热点数据 ?
A：使用allkeys-lru(挑选最近最少使用的数据淘汰)淘汰策略，留下来的都是经常访问的热点数据

Q：Redis的内存用完了会发生什么？
A：主要看数据淘汰策略是什么；如果是默认的配置（ noeviction ），会直接报错

六、Redis分布式锁

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

1.使用

获取锁：

# 添加锁，NX是互斥、EX是设置超时时间
SET lock value NX EX 10

释放锁：

# 释放锁，删除即可
DEL key

2.可重入

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

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

3.主从一致性问题

Redisson锁不能解决主从数据一致的问题，可以使用RedLock解决

RedLock(红锁)：不能只在一个redis实例上创建锁，应该是在多个redis实例上创建锁(n / 2 + 1)，避免在一个redis实例上加锁。

• 实现复杂
• 性能差

需要强一致可以使用zk

七、Redis集群方案

1.主从复制

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

image.png

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

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

1.1 全量同步

1.从节点请求主节点同步数据（replication id、 offset ）
2.主节点判断是否是第一次请求，是第一次就与从节点同步版本信息（replication id和offset）
3.主节点执行bgsave，生成rdb文件后，发送给从节点去执行
4.在rdb生成执行期间，主节点会以命令的方式记录到缓冲区（一个日志文件）
5.把生成之后的命令日志文件发送给从节点进行同步

全量同步.png

1.2 增量同步

1.从节点请求主节点同步数据，主节点判断不是第一次请求，不是第一次就获取从节点的offset值
2.主节点从命令日志中获取offset值之后的数据，发送给从节点进行数据同步

增量同步.png

2.哨兵模式

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。

image.png

哨兵的作用：

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

2.1服务状态监控

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

• 主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
• 客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

2.2 哨兵选主规则

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

image.png

2.3 脑裂问题

image.png

集群脑裂是由于主节点和从节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到主节点，所以通过选举的方式提升了一个从节点为主，这样就存在了两个master，就像大脑分裂了一样。
这样会导致客户端还在老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将老的主节点降为从节点，这时再从新master同步数据，就会导致数据丢失。

解决：可以修改redis的配置，设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的数据丢失

redis中有两个配置参数：

• min-replicas-to-write 1 表示最少的salve节点为1个
• min-replicas-max-lag 5 表示数据复制和同步的延迟不能超过5秒

3.分片集群

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

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

3.2 分片集群特征

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

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

image.png

3.2数据读写

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

读写数据：根据key的有效部分计算哈希值，对16384取余（有效部分，如果key前面有大括号，大括号的内容就是有效部分，如果没有，则以key本身做为有效部分）余数做为插槽，寻找插槽所在的实例

image.png

八、Redis为什么这么快

• Redis是纯内存操作，执行速度非常快
• 采用单线程，避免不必要的上下文切换可竞争条件，多线程还要考虑线程安全问题
• 使用I/O多路复用模型，非阻塞IO

8.1 I/O多路复用模型

Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度， I/O多路复用模型主要就是实现了高效的网络请求。

• 用户空间和内核空间
• 常见的IO模型
  • 阻塞IO（Blocking IO）
  • 非阻塞IO（Nonblocking IO）
  • IO多路复用（IO Multiplexing）
• Redis网络模型

8.2 用户空间和内核空间

Linux系统中一个进程使用的内存情况划分两部分：

• 内核空间：可以执行特权命令（Ring0），调用一切系统资源
• 用户空间：只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问

image.png

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：

• 写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备
• 读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

8.3 阻塞IO

顾名思义，阻塞IO就是两个阶段都必须阻塞等待：

阶段一：

• 用户进程尝试读取数据（比如网卡数据）
• 此时数据尚未到达，内核需要等待数据
• 此时用户进程也处于阻塞状态

阶段二：

• 数据到达并拷贝到内核缓冲区，代表已就绪
• 将内核数据拷贝到用户缓冲区
• 拷贝过程中，用户进程依然阻塞等待
• 拷贝完成，用户进程解除阻塞，处理数据

image.png

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

8.4 非阻塞IO

非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

阶段一：

• 用户进程尝试读取数据（比如网卡数据）
• 此时数据尚未到达，内核需要等待数据
• 返回异常给用户进程
• 用户进程拿到error后，再次尝试读取
• 循环往复，直到数据就绪

阶段二：

• 将内核数据拷贝到用户缓冲区
• 拷贝过程中，用户进程依然阻塞等待
• 拷贝完成，用户进程解除阻塞，处理数据

image.png

非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

8.5 IO多路复用

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

阶段一：

• 用户进程调用select，指定要监听的Socket集合
• 内核监听对应的多个socket
• 任意一个或多个socket数据就绪则返回readable
• 此过程中用户进程阻塞

阶段二：

• 用户进程找到就绪的socket
• 依次调用recvfrom读取数据
• 内核将数据拷贝到用户空间
• 用户进程处理数据

image.png

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

• select
• poll
• epoll

差异：

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

8.6 Redis网络模型

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

使用I/O多路复用结合事件的处理器来应对多个Socket请求

• 连接应答处理器
• 命令回复处理器：在Redis6.0之后，为了提升更好的性能，使用了多线程来处理回复事件
• 命令请求处理器：在Redis6.0之后，将命令的转换使用了多线程，增加命令转换速度，在命令执行的时候，依然是单线程

image.png