深度长文整理-Redis进阶
阅读原文时间:2024年05月24日阅读:1

目录

一、基础

重新整理了一下,这篇笔记之前还有一篇基础相关的笔记,点击进入

二、为什么Redis是单线程的?

官方回答:

Redis是基于内存操作,CPU不是Redis的性能瓶颈,Redis的性能瓶颈是机器的内存大小、以及网络的带宽,既然单线程容易实现,那就直接使用单线程来实现了

此外:

使用单线程实现,那所有的命令就会排队执行,不需要考虑各种同步问题和加锁带来的性能消耗问题。

既然CPU不是Redis的瓶颈,那么如果不想让服务器的其他CPU闲置,可以考虑起多个Redis进程,因为Redis不是关系型数据库,数据之间也没有约束。这样还能搭建集群,分压分流。

三、为什么单线程这么快?

  1. Redis是一款内存数据库,基于内存的读写速度本来就很快
  2. 如果使用多线程的话会有线程上下文的切换。对于内存系统来说,单线程操作内存的效率才是最高的。
  3. Redis使用了epoll IO多路复用,可以实现用一条线程处理并发的网络请求

四、select、poll、epoll

select、poll、eopll是操作系统处理网络上传输过来的数据的不同实现,数据从经过网线流入网卡,网卡中的驱动程序会向CPU发出中断信号,在交互系统中,中断信号的优先级是很高的,CPU立刻去处理这个中断信息,CPU通过终端表找到相应的处理函数:

1、禁用网卡的中断信号,告诉网卡下次有数据过来直接写内存就ok

2、通过驱动程序申请、初始化一块内存,将网卡中的数据写进内存中

3、然后解析处理数据:操作系统先校验数据是否符合os structure、数据往上层传递,Ehthernet校验数据是否符合预期的格式,继续向上层传递到ip层,再往上到tcp/udp层并按照指定的协议去解析

4、应用层想使用这部分数据就有一个拆包+格式校验的过程

内存指的的socket文件的接受缓冲区。

作为一个网络服务器同一时刻可能有多个socket和他建立连接与他进行数据的交互,这里的select、poll、epoll说的其实就是在众多的socket中如何快速高效的找到接受缓冲区存在数据的socket文件,然后交给应用层的代码去处理它

Select模型

操作系统为每一个Tcp连接都会相应的创建sock文件,这些sock文件隶属于操作系统的文件列表。

当sock2收到了数据,会调用中断程序唤醒进程A,将进程A从所有的Sock的等来队列中移除,加入到内核空间的工作队列中进程A只知道至少有一个sock的接受缓冲区已经由数据了,但是它不知道到底是哪个sock,所以它得通过遍历sock列表的方式找到这个sock。

select的缺点和不足:

  1. 进程A需要添加进所有的sock的等待队列中,这会进行一次遍历。
  2. 当有sock就收到数据时,又得将进程A从所有的sock等待队列中移除,这又是一次遍历。
  3. 进程A寻找有数据的sock时,还会发生一次遍历。
  4. 为了放置单个进程将系统的所有资源都耗干,linux会限制单个进程能打开的fd文件句柄数,即使你可以修改配置,突破这会个限制

Poll模型

poll本质上和select没有区别,都会进行好几次无谓的遍历才能找到到底是那个sock文件的接受缓冲区中接受到了数据。

优点:它没有最大连接数的限制,原因是它是基于链表来存储的文件句柄的

Epoll模型

Epoll的设计目标就是优化掉Select 和 Poll模型中查找接收到数据的sock文件时进行的无谓的遍历操作。

看上图:在select模型中,需要将进程添加进每一个sock的等待队列,然后阻塞,假如10万TCP连接对应着10万个sock文件,那这个添加+阻塞的操作就得重复10万次

对于epoll来说可以看到,这个添加的过程只进行了一次…见下图

int s = socket(AF_INET, SOCK_STREAM, 0);
bind(s, ...)
listen(s, ...)

int epfd = epoll_create(...);
epoll_ctl(epfd, ...); //将所有需要监听的socket添加到epfd中

while(1){
    int n = epoll_wait(...)
    for(接收到数据的socket){
        //处理
    }

当执行系统调用 epoll_create(…) 内核会创建上图中的eventpoll对象,eventpoll对象也隶属于操作系统的文件系统,此外所有的sock都注册在eventpoll中。

进程不再注册在每一个sock的等待队列中,而是注册在eventpoll的等待队列中,此外,接受缓冲区存在数据的sock会被注册进eventpoll的rdlist中。这样当进程再次被唤醒添加到操作系统的工作队列中时,从eventpoll的rdlist中就能确切的获取到哪些sock是需要处理的sock,免去了遍历之苦

Epoll的连接数有上限,但是很大,1G内存的机器上可以打开10万左右的连接,2G内存的机器可以打开20万左右的连接。

参考(这个大佬讲的超级好):https://zhuanlan.zhihu.com/p/63179839

五、Redis的事物

原子性:一组命令要么同时成功,要么同时失败

但是redis中的每一条单独的命令是有原子性的,但是Redis中的事物不能保证原子性

redis中的事物没有隔离级别的概念,不可能出现脏读、幻读、不可重复读

在redis中,事物的本质是一组命令的集合,一个事物中的所有命令都会有被序列化,在事物执行的过程中:顺序、排他、一次性执行。

Redis事物的过程:

  • 开启事物

  • 一连串普通命令

  • 执行事物

    开启事物

    127.0.0.1:16379> MULTI
    OK

    添加命令

    127.0.0.1:16379> SET k1 v1
    QUEUED
    127.0.0.1:16379> SET k2 v2
    QUEUED

    执行事物

    127.0.0.1:16379> EXEC
    1) OK
    2) OK
    127.0.0.1:16379>

    开启事物

    127.0.0.1:16379> MULTI
    OK

    添加命令

    127.0.0.1:16379> set k3 v3
    QUEUED
    127.0.0.1:16379> SET k4 v4
    QUEUED

    取消事物

    127.0.0.1:16379> DISCARD
    OK

    检查结果,确实没有执行刚刚添加的命令

    127.0.0.1:16379> keys *
    1) "k1"
    2) "k2"
    127.0.0.1:16379>

假设开启时候后,多条命令中有一个命令出现运行时异常有什么影响?

出现异常的命令不会被执行,但是这个异常的命令不会影响它后面的命令执行,因为这个原因我们说redis的事物不支持原子性

# k1的值为字符串
127.0.0.1:16379> set k1 "v1"
OK
# 开启事物
127.0.0.1:16379> MULTI
OK
# 设置事物的值
127.0.0.1:16379> set k2 v2
QUEUED
# 对字符串类型的值+1,会抛出运行时异常
127.0.0.1:16379> INCR k1
QUEUED
# 继续添加两个值
127.0.0.1:16379> set k3 v3
QUEUED
127.0.0.1:16379> set k4 v4
QUEUED
# 执行事物,看到,运行时异常的命令不会影响后续的命令执行
127.0.0.1:16379> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
4) OK
127.0.0.1:16379>

假设开启时候后,多条命令中有一个命令出现编译异常有什么影响?

出现编译型异常,所有的命令都不会被执行

# 开启事物
127.0.0.1:16379> MULTI
OK
# 往命令队列中添加命令
127.0.0.1:16379> set k1 v1
QUEUED
127.0.0.1:16379> set k2 v2
QUEUED
# 故意添加一个语法错误的命令,导致编译异常
127.0.0.1:16379> GETSET k3
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:16379> set k4 v4
QUEUED
# 执行事物
127.0.0.1:16379> exec
(error) EXECABORT Transaction discarded because of previous errors.
# 检查结果,发现所有的命令都没有被执行
127.0.0.1:16379> keys *
(empty list or set)
127.0.0.1:16379>

CAP理论

nosql同样也有一套属于自己的CAP

  • C(Consistency 强一致性)
  • A(Availability可用性)
  • P(Partition tolerance分区容错性)

CAP 的理论核心是: 一个分布式的系统,不可能很好的满足一致性,可用性,分区容错性这三个需求,最多同时只能满足两个.因此CAP原理将nosql分成了三大原则:

  • CA- 单点集群,满足强一致性和可用性,比如说oracle,扩展性收到了限制
  • CP- 满足一致性,和分区容错性Redis和MongoDB都属于这种类型
  • AP- 选择了可用性和分区容错性,他也是大多数网站的选择,容忍数据可以暂时不一致,但是不容忍系统挂掉

六、Redis的监控

redis可使用watch监视某一个key,然后开启事物操作某一个key,当key没有发生异常变动时,事物正常结束

一旦事物成功执行后,watch就会自动取消掉

127.0.0.1:16379> set money 100
OK
127.0.0.1:16379> set out 0
OK
# 监视key
127.0.0.1:16379> WATCH money
OK
127.0.0.1:16379> MULTI
OK
127.0.0.1:16379> DECRBY money 20
QUEUED
127.0.0.1:16379> INCRBY out 20
QUEUED
127.0.0.1:16379> exec
1) (integer) 80
2) (integer) 20

下面演示一个出现异常的例子:

事物中,添加watch的key被修改后,执行事物返回nil,表示失败

验证了watch机制使用的是乐观锁机制

当遇到上面这种返回nil的情况下,可以像下面这样处理

# 取消监视(解锁)
127.0.0.1:16379> UNWATCH
OK
# 重新监视
127.0.0.1:16379> watch money
OK
# 重新开启事物
127.0.0.1:16379> MULTI
OK
127.0.0.1:16379>

七、Redis的配置文件

## 启动redis的方式
./redis-server /path/to/redis.conf

# 可以像下面这样让在当前配置文件包含引用其他配置文件
include /path/to/local.conf
include /path/to/other.conf

# 指定哪些客户端可以连接使用redis
Examples:
bind 192.168.1.100 10.0.0.1  # 指定ip
bind 127.0.0.1 ::1 # 仅限于本机可访问

# 是否处于受保护的模式,默认开启
protected-mode yes

# 对外暴露的端口
port 16379

# TCP的通用配置
tcp-backlog 511
timeout 0
tcp-keepalive 300

# 是否以守护进程的方式运行,默认为no
daemonize yes

# 如果进程在后台运行,需要指定这个pid文件
pidfile /var/run/redis_6379.pid

# 日志级别
# debug 测试开发节点
# verbose (和dubug很像,会产生大量日志)
# notice (生产环境使用)
# warning (only very important / critical messages are logged)
loglevel notice

# 日志文件名
logfile ""

# 数据库的数量,默认16个
databases 16

# 是否总是显示logo
always-show-logo yes

# 设置redis的登陆密码(默认没有密码)
# 设置完密码后,使用redis-cli登陆时,使用auth password 认证登陆
requirepass foobared

# 设置能连接上redis的客户端的最大数量
maxclients 10000

# 给redis设置最大的内存容量
maxmemory <bytes>

# 内存达到上限后的处理策略
# volatile-lru -> 只针对设置了过期时间的key进行LRU移除
# allkeys-lru -> 删除LRU算法的Key
# volatile-lfu -> 使用具有过期集的密钥在近似的LFU中进行驱逐。
# allkeys-lfu -> 使用近似的LFU退出任何密钥。
# volatile-random -> 随机删除即将过期的key
# allkeys-random -> 随机删除
# volatile-ttl -> 删除即将过期的
# noeviction -> 永不过期,返回错误
maxmemory-policy noeviction

八、Redis的持久化

8.1、fork()系统调用

这里很突兀的来个fork()系统调用原因是应为:Redis的单线程的,那如果主线程去做这种耗时的IO同步操作时,Redis整体的性能会被拖垮的。

fork()它是一个系统调用,一般用它来创建一个和当前进程一模一样的子进程。当在程序中调用它时,系统为新的进程分配存储、资源,将原程序中的值也复制给他。

fork()函数调用一次会返回两次,在父进程得到的返回值是子进程的pid,在子进程中得到的是0,出错则返回负数。

Redis的实现是通过fork()系统调用创建一个子进程。 由这个子进程去负责执行这些耗时的IO操作,父子进程会共享内存,然后被共享的这块内存不可写,新的数据写入到新的内存文件中

8.2、RDB

写RDB文件是Redis的一种持久化方式。在指定的时间间隔内将内存中的数据写入到磁盘,RDB文件是一个紧凑的二进制文件,每一个文件都代表了某一个时刻(执行fork的时刻)Redis完整的数据快照,恢复数据时,将快照文件读入内存即可。

RDB持久化的详细过程:

Redis会通过系统调用fork()出一个子进程,父子进程是会共享内存的,父进程和子进程共享的这块内存就是在执行fork操作那个时刻的内存快照。由linux的copy on write机制将父子进程共享的这块内存标记为只读状态。

此时对子进程来说,它的任务就是将这块只读内存中的数据保存成RDB文件。

对父进程来说它是有可能收到写命令的,当父进程尝试往这个加了只读状态的内存地址写入数据时,就会触发保护异常,执行linux的 copy on write,也就是将原来内存对应的数据页复制出来一份后,然后对这个副本进行修改。

这里就会出现一个丢数据的概念:你想,fork出来的子进程将要保存的数据是执行fork系统调用那个时刻的内存中的数据,很快这个内存就被标记为只读了,后续的增量数据没有写入到这个只读内存中,那就算是RDB成功生成了,这些增量的数据依然会丢(所以得使用AOF辅助)

第二种RDB出现数据的丢失的情况是:RDB过程中,直接失败了,文件都没生成,不光是增量数据,原来的数据都丢了。

参考:linux的copy on write

欢迎关注大佬:三国梦回

RDB相关配置如下

# 把下面的注释打开就会禁用掉RDB的持久化策略
# save ""

# 快照相关,指的是在规定的时间内执行了多少次操作才会持久化到文件
save 900 1 # 900秒内1次
save 300 10 # 300秒内10次
save 60 10000 # 60秒内1万次

# 持久化出错了,是否让redis继续工作
stop-writes-on-bgsave-error yes

# 是否压缩RBD文件(redis会采用LZF压缩算法进行压缩)需要消耗CPU资源
rdbcompression yes

# 保存rbc文件时是否检验rbd文件格式
# 使用CRC64算法进行数据校验,但是这样会增加大约 10%的性能消耗
rdbchecksum yes

# dump DB的文件名
dbfilename dump.rdb

# rdb文件的持久化目录(当前目录)
dir ./

触发保存RDB文件4种情况

  1. 手动执行save命令、bgsave
  2. 满足配置文件中配置的save相关配置项时,自动触发
  3. 手动执行flushall
  4. 关闭redisshutdown

如何让redis加载rdb文件?

只需要将rdb文件放在redis的启动目录下,redis其中时会自动加载它

RDB模式的优缺点:

优点:RDB过程中,由子进程代替主进程进行备份的IO操作。保证了主进程仍然提供高性能的服务。适合大规模的数据备份恢复过程。

缺点:

  1. 默认情况下,它是每隔一段时间进行一次数据备份,所以一旦出现最后一次持久化的数据丢失,将丢失大规模的数据。
  2. fork()子进程时会占用一定的内存空间,如果在fork()子进程的过程中,父进程夯住了,那也就是redis卡住了,不能对外提供服务。所以不要让生成RDB文件的时间间隔太长,不然每次生成的RDB文件过大对Redis本身也是有影响的。

8.3、AOF

AOF是什么?

Append Only File,他也是Redis的持久化策略。即将所有的写命令都以日志的方式追加记录下来(只追加,不修改),恢复的时候将这个文件中的命令读出来回放。

当我们执行 flushall 命令,清空了redis在内存中的数据,appendonly.aof 同样会记录下这条命令,所以,我们想恢复数据的话,需要去除 appendonly.aof 里面的 flushall 命令

AOF相关的配置

# 默认不开启aof
appendonly no

# aof文件名
appendfilename "appendonly.aof"

# redis通过fsync()调用告诉操作系统实际在磁盘上写入数据
# aof文件落盘的策略
# appendfsync always 每次发生数据变更,立刻记录到磁盘,但是导致redis吞吐量降低
# appendfsync everysec 可能会丢失1秒的数据
# appendfsync no
appendfsync everysec

# 当时用bfwriteaof时,fork一个子进程写aof文件,就算aof文件很大,也不会阻塞主进程
# 意外情况:但是当主进程、子进程同时写aof文件时,可能会出现由于子进程大量的IO操作阻塞主进程
# 当出现这种意外情况时:设置这个参数为no,可以保证数据不会丢失,但是得容忍主进程被阻塞
# 当出现这种意外情况时:设置这个参数为yes,主进程不会被阻塞主,但是不保证数据安全性
# 综上:如果应用无法忍受延迟:设置为yes。无法忍受数据丢失:设置为no
no-appendfsync-on-rewrite no

# 在当前aof文件的体积超过上次aof文件的体积的100%时,写新文件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb # 最开始的aof文件体积至少达到60M时才重写

# 回放aof文件时,如果最后一条命令存在问题,是否允许忽略
aof-load-truncated yes

# 是否允许AOF和RDB这两种持久化方式并存
aof-use-rdb-preamble yes

当aof文件出错怎么办?

redis为我们提供了修复aof文件的工具

[root@instance-lynj0v9k-19 bin]# redis-check-aof  --fix appendonly.aof

aof模式的优缺点
优点:

  1. aof是用追加的形式写,没有随机磁盘IO那样的寻址开销,性能还是比较高的。
  2. aof可以更好的保护数据不丢失或者尽可能的少丢失:设置让redis每秒同步一次数据,即使redis宕机了,最多也就丢失1秒的数据。
  3. 即使aof真的体积很大,也可以设置后台重写,不影响客户端的重写。
  4. aof适合做灾难性的误删除紧急恢复:比如不小心执行了flushall,然后可以在发生rewrite之前 快速备份下aof文件,去掉末尾的 flushall,通过恢复机制恢复数据

缺点:使用aof一直追加写,导致aof的体积远大于RDB文件的体积,恢复数据、修复的速度要比rdb慢很多。

aof的重写

AOF采取的是文件追加的方式,文件的体积越来越大,为了优化这种现象,增加了重写机制,当aof文件的体积到达我们在上面的配置文件上的阕值时,就会触发重写策略,只保留和数据恢复相关的命令

手动触发重写

# redis会fork出一条新的进程
# 同样是先复制到一份新的临时文件,最后再rename,遍历每一条语句,记录下有set的语句
bgrewriteaof

8.4、RDB和AOF的选择

  • 如果我们的redis只是简单的作为缓存,那两者都不要也没事
  • 如果数据需要持久化,那不要仅仅使用RDB,因为一旦发生故障,你会丢失很多数据
  • 同时开启两者: 在这种情况下,redis优先加载的是aof,因为它的数据很可能比rdb更全,但是并不建议只是用aof,因为aof不是那么的安全,很可能存在潜在的bug

推荐:

  • 建议在从机slave上只备份rdb文件,而且只要15分钟备份一次就够了。
  • 如果启动了aof,我们尽量减少rewrite的频率,基础大小设置为5G完全可以,起步也要3G。
  • 如果我们不选择aof, 而是选择了主从复制的架构实现高可用同样可以,能省掉一大笔IO操作,但是意外发生的话,会丢失十几分钟的数据。

九、发布订阅

Redis的发布订阅模型是一种:消息通信方式,发布者发送到redis到队列中,消息的订阅者可以接收到消息,Redis的客户端可以订阅任意数量的消息

应用场景:关注订阅、消息推送、实时广播、网络聊天室

有新消息通过 PUBLISH 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个客户端

测试发布、订阅

十、主从复制

概念:和MySQL的主从复制的概念大同小异,分成leader节点和follower节点,主节点承接线上的写流量,从节点承接线上的读流量为主库分流减压,从库的数据从主库中同步过来

主从复制的作用:

  1. 理论上主库从库的数据是需要保持的,这也是一种数据冗余热备份的机制
  2. 故障恢复:当leader节点出现故障时,可以由从节点提供服务,保证应用的可用性
  3. 负载均衡:在主从复制的接触上,可以将客户端的读写不同类型的流量分摊到不同的机器上,分流减压
  4. 主从复制+哨兵,构建高可用的redis集群,解决了单点故障问题

十一、集群搭建及小实验

redis默认自己就是一个主库,所以我们搭建主从架构的redis,只需要配置Redis从库。

11.1、架构一:一主两从

下面搭建这样的一主两从的redis集群

role

ip

port

主库

xxx

16379

从库

xxx

16378

从库

xxx

16377

如果是在一台服务器上启动多台Redis,需要修改一下配置文件中的端口、pid文件名、日志名、dump.db名

启动三台redis

让16378、16377认16379为leader,执行如下命令:

搭建完主从环境之后,查看是否可以从slave中写入数据:

# 结果很明显,不能写入
127.0.0.1:16378> set k1 v0
(error) READONLY You can't write against a read only replica.

MySQL中只要你不设置从库read only,从库也是可以写入的并产生自己的binlog的

测试:从master写入,从slave读出

测试:主机宕机,slave有什么表现

主机宕机后,从库的role依然是slave,并且显示master的状态为down

测试:主机宕机后又重启了,slave有什么表现

主机重启后,slave会重连主机,主机的状态为up,salve可以正常在主库上同步数据

测试:从机宕机,然后有新数据写到了主库,从机再重启问:重启后的从机能不能获取到她宕机期间主库的增量数据?

答案是:获取不到了,因为如果是通过命令行搭建的主从,从库一旦重启,角色会变回master

如果这时再把16378变成16379的从库,问能不能获取到增量数据呢?

全量复制和增量复制

从库第一次连接到主库上肯定会进行一次全量复制,即:master会启动后台的存盘进程,同时收集所有用于修改数据集的命令,在后台完成同步,然后将整个数据文件发送给slave,让slave完成一次数据的全量复制

除第一次复制数据之外的主从复制都是增量复制,即master仅仅会将收到的增量写命令发送给slave。

11.2、架构二

其中的17378既是Master又是Slave

对于16377来说,它确实认了16378为主,但是16378本身又是16379的slave,所以他们之间数据同步的走向是 : 16379 --> 16378 --> 16377 ,对于16378来说,即使有实例认它当master,它依然是不能写

如果主库16379宕机了,16378的状态依然是slave,并且它能察觉master已经挂了,执行 slave no one, 可以将自己提升为master。 在整个过程中,16377不受影响

即使旧master开机重启了,旧的master依然是master,也不能自动的加入到 16377 16378集群中

11.3、架构三:Sentinel

上面的两种架构模式中,主库挂了之后都需要人为的去选举一个的新的master来承接读流量

redis2.8之之后,提供了哨兵模式:哨兵监控到当主服务器挂了,发起投票选新主库,实现自动的完成选主,承接线上写流量,完成止损

哨兵作为一个独立的进程存在,原理是:哨兵通过发送命令和redis服务器交互,从而监控运行整个集群中的多个Redis实例

Redis的哨兵在Redis 的安装目录下可以找到

为了防护哨兵出现单点故障,所以通常使用多个哨兵对集群进行监控

集群中的每个哨兵彼此相互监控,每个哨兵也都监控着集群中的所有Redis实例

主观下线和客观下线

当一个哨兵发现master不可用时,系统不会马上进行failover,仅仅是这一个哨兵主观意义上认为这个master不可用,这时如果其他的哨兵也来探测master,并且大部分的哨兵都主观认为master确实不可用了,哨兵们就会投票在slave中选出一个当得票最多的slave作为新的master。进行failover操作。

通过发布订阅的模式,哨兵告诉自己监控的那些服务器将master切换为刚刚的票最多的那个实例,这个过程就叫做客观下线

集群搭建

首先是创建一主二从的redis集群, 此处省略,参照上面架构1部分即可

编写sentinel的配置文件,配置文件的名称、配置项不能写错~

# myredis1 监控的这个redis实例啥
# 127.0.0.1 监控的这个redis实例的ip
# 16379 监控的这个redis实例的端口
# 1 监控的这个redis实例的挂了后,自动投票选主
sentinel monitor myredis1 127.0.0.1 16379 1

启动sentinel

这样,当master宕机后,哨兵会自动选择一个新的slave作为新主,主库重启后,sentinel会将其作为slave自动加入到现有的redis集群中

更多更详细的sentinel配置文件可以看看这个博文:https://www.cnblogs.com/heroinss/p/10340925.html

十二、缓存穿透、缓存击穿、雪崩

缓存穿透

比如这种应用场景:使用redis缓存用户信息,当有新用户注册时先将用户的信息写入Redis,然后写入Mysql,有修改操作时,修改完MySQl中的数据后,同步的也会修改Redis中的数据,而且我们也没有给Redis中的key设置过期时间。(这就意味着,数据库中有指定的KV的信息的话,缓存中也会有。那当用户查询时缓存中没有的话,说明数据库中99.999%也不会有)

这时候有大量的请求突然打向了Redis,Redis中又没有存储用户查询的数据,大量的请求一下子打到了数据库上,瞬间击垮数据库,这种现象称为缓存穿透。

解决方案:

布隆过滤器:

布隆过滤器可以理解成一个bit数组,数组中每一个非0即1

客户端的请求统一先打向布隆过滤器,布隆过滤器放在应用的控制层,布隆过滤器中存在多个hash函数,分别对这个key进行hash得到hashcode,然后将hashcode%数组长度,将算出来的下标标记为1。

key以此经过所有hash,再%size算出的下标对应的值,只要存在一个不为1的数,我们就认为key没在缓存中,直接丢弃用户的这次请求,符合要求把请求打向Redis。从而避免这个请求对底层存储的查询压力。

缓存空对象:

当用户查询的时候,如果发现缓存中没有,就往缓存中放置一个空的对象,然后返回给用户这个控对象,也能避免用户的请求直接打向数据库。

缓存击穿:

缓存击穿指的是Redis中确确实实存在用户查询的key,但是呢用户的访问频率太猛烈了,导致Redis扛不住挂了,导致大量的请求直接打向数据库,或者当某一个key的过期时间到了的瞬间,大量的请求打向数据库导致数据库直接挂了

解决方案:

设置key永不过期

加互斥锁:对这个查询操作添加分布式锁,将原来的大并发直接访问缓存转换成了并发获取分布式锁,只有获取到分布式锁后才能去查询缓存。

雪崩:

比我们启动redis进行一些数据预热,就是将一些数据库中的数据提前导入到redis中,然后给这些数据设置了过期时间。

抢购时间一到系统迎来了一大批并发,但是由于缓存中的数据充足,所以能扛住这波并发。一段时间后,redis中的key集中式的过期了,这时再来一大批并发请求可能就直接将redis打垮。redis挂了后,大量的请求直接打向MySQL,导致MySQL跟着雪崩式的垮掉

解决方法:

异地多活,添加redis的实例的数量

加分布式锁

在应用和缓存之间添加消息中间件做缓冲

合理为不同的key设置不同的过期时间,放置缓存中的key出现集中式过期的情况