Redis学习笔记

最新推荐文章于 2024-09-07 16:01:40 发布

blablablalalala

最新推荐文章于 2024-09-07 16:01:40 发布

阅读量170

点赞数

文章标签： redis 数据库 java

本文链接：https://blog.csdn.net/qq_52398006/article/details/129832090

版权

文章详细介绍了Redis的事务机制，包括Multi、Exec、Discard指令，以及事务的错误处理和乐观锁概念。此外，还阐述了Redis的持久化方式，如RDB快照和AOF日志，以及它们的优缺点。接着讨论了主从复制的原理和哨兵模式，用于高可用性和故障恢复。最后提到了Redis集群和应对缓存穿透、缓存击穿的问题，以及分布式锁的实现和优化策略。

摘要由CSDN通过智能技术生成

已在宝塔面板中的redis添加了命令，故在启用redis服务时需要添加密码：auth 密码

在springboot整合redis时也需要在配置文件中添加密码：

spring:
    redis:
    host: 公网ip
    port: 6379
    database: 0
    timeout: 1800000
    password: 密码
    lettuce:
        pool:
        max-active: 20
        max-wait: 1
        max-idle: 5
        min-idle: 0

1.事务和🔒机制

1.1 什么是事务

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis事务的主要作用就是串联多个命令防止别的命令插队。

1.2 Multi、Exec、discard指令

事务流程：

开启：以multi开始一个事务；
入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面；
执行：由exec命令触发事务；

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行（相当于开启事务），直到输入Exec后，Redis会将之前的命令队列中的命令依次执行（执行事务）。

在输入Multi命令开启事务后，可以再输入discard来放弃组队。

组队成功，提交成功

1.3 事务错误的处理机制

组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。

案例：

组队阶段报错，提交失败

如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

案例：

组队成功，提交有成功有失败情况

1.4 事务冲突和🔒机制

案例引入：

一个请求想给金额减8000

一个请求想给金额减5000

一个请求想给金额减1000

由图可知，当事务完全执行后，账户里就变成了-4000，这与实际意义不符。

1.4.1 悲观🔒

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

1.4.2 乐观🔒

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。（在Redis中所用的就是乐观锁）

1.5 WATCH key [key......]

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

案例：

例如，我们使用watch命令监视babance，当开启事务后，添加命令。在exec执行前，我们又在另外一个客户端（下图）对balance进行修改命令，那么此客户端的事务就会被打断。

unwatch命令可以取消所有WATCH对所有key的监视，但是如果在执行WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。

1.6 Redis事务三大特性

☀️单独的隔离操作

事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

☀️没有隔离级别的概念

队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

☀️不保证原子性

事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

2. 持久化

2.1 RDB

2.1.1 什么是RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

2.1.2 备份是怎么执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

2.1.3 FORK

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”（即fork子进程写入临时空间，然后同步至rdb文件中）
一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

2.1.4 dump.rdb文件

在redis.conf中配置文件名称，默认为dump.rdb（用来保存数据），在默认情况下，Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。

文件保存位置（可以修改）在：

rdb备份：可以将dump.rdb文件文件拷贝存储起来，在下次启动redis服务前将备份文件拷贝到工作目录下，启动redis服务后会自动加载备份文件的信息。

2.1.5 RDB使用策略

自动：按照配置文件中的条件满足就执行BGSAVE
save 60 10000，Redis要满足在60秒内至少有10000个键被改动，会自动保存一次（可以自己设置规则）
手动：客户端发起SAVE、BGSAVE命令

2.1.6 SAVE和BGSAVE命令

SAVE：在redis 客户端使用 save命令用于将数据持久化的保存到disk(磁盘)中，但执行该命令时会阻塞Redis服务，无法响应客户端请求，也就是在服务器执行save命令期间，Redis服务器不允许执行其它的命令直到save命令执行完，执行save命令会创建新的dump.rdb替代旧文件。

BGSAVE（该命令是在后台执行的，是一个异步命令）:在redis客户端使用 bgsave命令时，不会阻塞Redis服务，也就是非阻塞，Redis服务正常接收处理客户端请求，并且Redis会folk()一个新的子进程来创建RDB文件，子进程处理完后会向父进程发送一个信号，通知它处理完毕，父进程用新的dump.rdb替代旧文件

区别：

SAVE不用创建新的进程，速度略快
BGSAVE需要创建子进程，消耗额外的内存
SAVE适合停机维护，服务低谷时段
BGSAVE适合线上执行

2.1.7 RDB的优缺点

优点

完全备份，不同时间的数据集备份可以做到多版本恢复
紧凑的单一文件，方便网络传输，适合灾难恢复
恢复大数据集速度较AOF快

缺点

会丢失最近写入、修改的而未能持久化的数据
folk过程非常耗时，会造成毫秒级不能响应客户端请求

2.2 AOF

2.2.1 什么是AOF

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作（AOF保存的是appendonly.aof文件）；

2.2.2 AOF执行流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

AOF默认不开启，可以在redis.conf中配置文件名称，默认为 appendonly.aof，AOF文件的保存路径，同RDB的路径一致。

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

2.2.3 AOF的修复/恢复

正常恢复
启动：修改默认的appendonly no，改为yes；
将有数据的aof文件复制一份保存到对应目录(目录通过config get dir命令获取)；
恢复：重启redis然后重新加载；
异常恢复
启动：修改默认的appendonly no，改为yes；
备份被破坏的aof文件；
修复：使用redis-check-aof --fix命令进行修复；
恢复：重启redis然后重新加载；

2.2.4 rewrite

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof；

2.2.5 重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似；

2.2.6 触发机制

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发；

2.2.7 AOF优缺点

优势

每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘性能较差但数据完整性比较好；
每秒同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失；
不同步：appendfsync no 从不同步；

劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb；
aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同；

2.3 总结

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储；
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大；
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式；
同时开启两种持久化方式
在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整；
同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
性能建议：

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1这条规则。

如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值 64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite 时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构；

3. 主从复制

3.1 什么是主从复制

主机数据更新后根据配置和策略，自动同步到备机的master（主机）/slaver（从机）机制，master以写为主，slave以读为主；

3.2 作用

读写分离；
容灾恢复；

3.3 主从应用

redis只需要配置从机（从库）

从库配置：执行命令slaveof 主库IP（本机IP）主库端口（想要作为主机的端口号）：
每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件；
执行命令info replication查看主从关系；

修改配置文件细节：

拷贝多个redis.conf文件；

include(写绝对路径)

开启daemonize yes；

配置pid文件的位置；

pidfile 文件位置

修改指定端口；

port 端口号

修改log文件名字；

修改dump.rdb名字；

dbfilename 自定义文件名.rdb

Appendonly 关掉或者换名字

案例（创建一主一从）：

首先将服务器中的公共的redis.conf文件拷贝到自己所用的文件目录中
新建redis6379.conf（作为主机），填写以下内容：

include /myredis/redis.conf 引入公共文件redis.conf（文件路径为自己拷贝的绝对路径）
pidfile /var/run/redis_6379.pid 配置pid文件的位置
port 6379 指定端口号
dbfilename dump6379.rdb 定义rdb文件的名称

新建redis6380.conf（作为从机），填写以下内容：

nclude /myredis/redis.conf 引入公共文件redis.conf（文件路径为自己拷贝的绝对路径）
pidfile /var/run/redis_6380.pid 配置pid文件的位置
port 6380 指定端口号
dbfilename dump6380.rdb 定义rdb文件的名称

设置从机：

命令：slaveof 10.0.16.8 6379 （slaveof <ip><port>）

这样以来就只能在主机上进行✍（写）操作，从机上可以进行读操作
可以用 info replication命令进行查看主（从）机的信息

3.4 主从复制的三种机制

一主多从

1. 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?

答：从头复制

1. 从机是否可以进行写或者set操作？

答：否

1. 主机挂掉后，从机会是怎样的情况？

答：从机会原地待命，等待主机重启后，会自动连接从机并进行正常的复制功能

1. 从机挂掉后，重启后会发生什么？

答：从机重新启动后，需要手动连接主机，并且重新成为从机后会自动复制主机上所有的数据

薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力。

中途变更转向：会清除之前的数据，重新建立拷贝最新的。

反客为主

主机宕掉后，从机升级为主机。
选择一个从机手动执行slaveof no one命令变更为主机，其他从机与该主机建立主从关系。

（主机挂掉后）

3.5 主从复制的原理

Slave启动成功连接到master后会发送一个sync命令
Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

即为：

当连接上主服务器之后，从服务器向主服务器发送进行数据同步消息
当主服务器接到从服务器发送过来的同步消息后，把主服务器数据进行持久化操作，rdb文件，把rdb文件发送从服务器，从服务器拿到rdb进行读取。
每次主服务器进行写操作之后，和从服务器进行数据同步（主服务器主动操作，从服务器只在首次主动和主服务器进行交互）

3.6 哨兵模式

即为反客为主模式的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
哨兵模式步骤：

1. 自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错
2. 配置哨兵,填写内容：

sentinel monitor mymaster 127.0.0.1 6379 1，其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。（哪个从机会被选举为主机呢？根据优先级别：slave-priority

原主机重启后会变为从机。）

1. 启动哨兵

执行命令：redis-sentinel /myredis/sentinel.conf （目录依照各自的实际情况配置，可能目录不同）；

问题：如果之前的master重启回来，会不会双master冲突？

不会造成双冲突，之前的master会成为slave。

3.7 缺点

复制延时
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

4. redis集群

4.1 问题引入

容量不够，redis如何进行扩容？

并发写操作，redis如何分摊？

另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。

解决方案：之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置（如下图，三个主节点是相互连通的）。

4.2 什么是集群

Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。

4.3 案例引入

制作六个实例：6379,6380,6381,6389,6390,6391

六个redis.conf文件配置基本信息：

include /home/bigdata/redis.conf 引入公共的redis.conf文件
port 6379（六个文件的端口号） 自定义端口号
pidfile "/var/run/redis_6379.pid" 自定义pid文件
dbfilename "dump6379.rdb" 自定义rdb文件
dir "/home/bigdata/redis_cluster"
logfile "/home/bigdata/redis_cluster/redis_err_6379.log"
cluster-enabled yes 打开集群模式
cluster-config-file nodes-6379.conf 设定节点配置文件名
cluster-node-timeout 15000 设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。

启动六个redis服务

redis-server xx/xxx/xx/redis.conf(自定义的conf文件)

将六个节点合成一个集群

组合之前，请确保所有redis实例启动后，nodes-xxxx.conf文件都生成正常。

合体：

cd /opt/redis-6.2.1/src 进入自己redis服务中src文件夹

输入命令：redis-cli --cluster create --cluster-replicas 1 192.168.11.101:6379 192.168.11.101:6380 192.168.11.101:6381 192.168.11.101:6389 192.168.11.101:6390 192.168.11.101:6391

此处不要用127.0.0.1，请用真实IP地址。

-c 采用集群策略连接，设置数据会自动切换到相应的写主机

通过 cluster nodes 命令查看集群信息

问题：

redis cluster 如何分配这六个节点?

一个集群至少要有三个主节点。

选项--cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。

4.4 什么是slot（插槽）

一个Redis 集群包含 16384 个插槽（hash slot），数据库中的每个键都属于这 16384 个插槽的其中一个，

集群使用公式CRC16(key) % 16384 来计算键 key 属于哪个槽，其中 CRC16(key) 语句用于计算键key 的CRC16 校验和。

集群中的每个节点负责处理一部分插槽。举个例子，如果一个集群可以有主节点，其中：

节点A 负责处理 0 号至5460 号插槽。

节点B 负责处理 5461 号至10922 号插槽。

节点C 负责处理 10923 号至16383 号插槽。

4.5 在集群中录入值

在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。
edis-cli客户端提供了 –c 参数实现自动重定向。

如redis-cli -c –p 6379 登入后，再录入、查询键值对可以自动重定向。

不在一个slot下的键值，是不能使用mget,mset等多键操作。

可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去。

查询集群中的值

CLUSTER GETKEYSINSLOT <slot><count> 返回 count 个 slot 槽中的键。（只能查看本节点所管辖的插槽范围内的值）

4.6 故障恢复

如果主节点下线？从节点能否自动升为主节点？注意：15秒超时

答：从节点自动升为主节点

主节点恢复后，主从关系会如何？

答：会自动成为原从节点（已自动升为主节点）从节点。

如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续?

答：如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么，整个集群都挂掉；

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。

4.7 优缺点

优点：

实现扩容
分摊压力
无中心配置相对简单

缺点：

多键操作是不被支持的
多键的Redis事务是不被支持的。lua脚本不被支持
由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

5. 缓冲穿透（重点）

5.1 问题引入

key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。（利用非正常的url访问使得服务器在redis缓存中查找不到数据，而一直在数据库中查找，从而使得服务器瘫痪）

5.2 解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

解决方案：

（1） 对空值缓存：

如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟（降低性能）

（2） 设置可访问的名单（白名单）：

使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

（3） 采用布隆过滤器：

(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。

布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)

将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

（4） 进行实时监控：

当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

6. 缓存击穿（重点）

6.1 问题引入

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。（1.主要体现在数据库的访问压力瞬间过大。2.redis里面没有出现大量key过期，只是某个瞬间有大量并发请求所对应的key过期。3.redis访问正常。）

6.2 解决方案

key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

方案：

（1）预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长

（2）实时调整：现场监控哪些数据热门，实时调整key的过期时长

（3）使用锁：

（1）就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。

（2）先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key

（3）当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；

（4）当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

7. 缓存雪崩（重点）

7.1 问题引入

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key。

（极少时间内，查询大量的key集中过期情况，致使数据库瘫痪）

正常访问：

缓存大量失效情况：

7.2 解决方案

（1） 构建多级缓存架构：

nginx缓存 + redis缓存 +其他缓存（ehcache等）

（2） 使用锁或队列：

用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况（性能降低）

（3） 设置过期标志更新缓存：

记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。

（4） 将缓存失效时间分散开：

比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

8. 分布式锁

8.1 redis实现分布式锁

redis:命令

EX second ：设置键的过期时间为 second 秒。

SET key value EX second 效果等同于 SETEX key second value 。

PX millisecond ：设置键的过期时间为 millisecond 毫秒。

SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。

NX ：只在键不存在时，才对键进行设置操作。

SET key value NX 效果等同于 SETNX key value(第一次设置键值可以，第二次就不行了需要解锁) 。

（如想同时设置锁和锁的过期时间命令为：SET key value nx ex second）

XX ：只在键已经存在时，才对键进行设置操作。

SET key value XX 等同于 SETXX key value

DEL：删除锁

DEL kye

8.3 代码中应用

@GetMapping("testLock")
public void testLock(){
    //1获取锁，setne
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111");
    //2获取锁成功、查询num的值
    if(lock){
        Object value = redisTemplate.opsForValue().get("num");
        //2.1判断num为空return
        if(StringUtils.isEmpty(value)){
            return;
        }
        //2.2有值就转成成int
        int num = Integer.parseInt(value+"");
        //2.3把redis的num加1
        redisTemplate.opsForValue().set("num", ++num);
        //2.4释放锁，del
        redisTemplate.delete("lock");

    }else{
        //3获取锁失败、每隔0.1秒再获取
        try {
            Thread.sleep(100);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

问题：setnx刚好获取到锁，业务逻辑出现异常，导致锁无法释放

解决：设置过期时间，自动释放锁

8.4 优化之设置锁的过期时间

设置过期时间有两种方式：

1. 首先想到通过expire设置过期时间（缺乏原子性：如果在setnx和expire之间出现异常，锁也无法释放）

2. 在set时指定过期时间（推荐）：

问题：可能会释放其他服务器的锁。

场景：如果业务逻辑的执行时间是7s。执行流程如下

1. index1业务逻辑没执行完，3秒后锁被自动释放。
2. index2获取到锁，执行业务逻辑，3秒后锁被自动释放。
3. index3获取到锁，执行业务逻辑
4. index1业务逻辑执行完成，开始调用del释放锁，这时释放的是index3的锁，导致index3的业务只执行1s就被别人释放。
5. 最终等于没锁的情况。

解决：setnx获取锁时，设置一个指定的唯一值（例如：uuid）；释放前获取这个值，判断是否自己的锁。

8.5 优化之UUID防误删

问题：删除操作缺乏原子性。

场景：

1. index1执行删除时，查询到的lock值确实和uuid相等

uuid=v1

set(lock,uuid)；

1. index1执行删除锁之前前，lock刚好过期时间已到，被redis自动释放

在redis中没有了lock，没有了锁。

1. index2获取了lock

index2线程获取到了cpu的资源，开始执行方法（加锁，加uuid）

uuid=v2

set(lock,uuid)；

1. index1执行删除，此时会把index2的lock删除

index1 因为已经在方法中了，所以不需要重新上锁。index1有执行的权限。index1已经比较完成了，这个时候，开始执行

删除的index2的锁！

8.6 优化之LUA脚本保证删除的原子性

使用lua脚本保证原子性：

@GetMapping("testLockLua")
public void testLockLua() {
    //1 声明一个uuid ,将做为一个value 放入我们的key所对应的值中
    String uuid = UUID.randomUUID().toString();
    //2 定义一个锁：lua 脚本可以使用同一把锁，来实现删除！
    String skuId = "25"; // 访问skuId 为25号的商品 100008348542
    String locKey = "lock:" + skuId; // 锁住的是每个商品的数据

    // 3 获取锁
    Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid, 3, TimeUnit.SECONDS);

    // 第一种： lock 与过期时间中间不写任何的代码。
    // redisTemplate.expire("lock",10, TimeUnit.SECONDS);//设置过期时间
    // 如果true
    if (lock) {
        // 执行的业务逻辑开始
        // 获取缓存中的num 数据
        Object value = redisTemplate.opsForValue().get("num");
        // 如果是空直接返回
        if (StringUtils.isEmpty(value)) {
            return;
        }
        // 不是空 如果说在这出现了异常！ 那么delete 就删除失败！ 也就是说锁永远存在！
        int num = Integer.parseInt(value + "");
        // 使num 每次+1 放入缓存
        redisTemplate.opsForValue().set("num", String.valueOf(++num));
        /*使用lua脚本来锁*/
        // 定义lua 脚本
        String script ="if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        // 使用redis执行lua执行
        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptText(script);
        // 设置一下返回值类型 为Long
        // 因为删除判断的时候，返回的0,给其封装为数据类型。如果不封装那么默认返回String 类型，
        // 那么返回字符串与0 会有发生错误。
        redisScript.setResultType(Long.class);
        // 第一个要是script 脚本 ，第二个需要判断的key，第三个就是key所对应的值。
        redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);
    } else {
        // 其他线程等待
        try {
            // 睡眠
            Thread.sleep(1000);
            // 睡醒了之后，调用方法。
            testLockLua();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

Lua脚本详情：

例子：

blablablalalala

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis学习笔记

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。Redis事务的主要作用就是串联多个命令防止别的命令插队。RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储；AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大；
复制链接

扫一扫