redis 发布和订阅 持久化 事务 缓存问题

发布时间:2022-10-01 16:00

redis的发布订阅 使用数据类型lists

原理
redis 发布和订阅 持久化 事务 缓存问题_第1张图片
可以有多个消费者和订阅者

订阅者:subscribe cla 命令
执行成功后
subscribe :表示成功订阅到响应
第二个元素:提供的频道
第三个参数代表订阅频道的数量
message:这是另一个客户端发出来的发布命令的结果
第二个元素:来源频道的名称
第三个参数:实际消息的内容

redis 发布和订阅 持久化 事务 缓存问题_第2张图片
发布者:publish cla ‘hello world’(字符间有空格要加上引号,否则会报错)
对应发布频道的内容打不成功会返回频道有几个数据
redis 发布和订阅 持久化 事务 缓存问题_第3张图片
匹配订阅:psubcribe cl* qudao* (模糊匹配查看这两个包含名称的频道的订阅内容)
redis 发布和订阅 持久化 事务 缓存问题_第4张图片

数据库与作用域:发布或者订阅与key所在的空间没有关系,不会受任何级别的干扰,包括数据库编码
redis 发布和订阅 持久化 事务 缓存问题_第5张图片
redis 发布和订阅 持久化 事务 缓存问题_第6张图片

redis的持久化

redis提供了两种方式进行持久化,一种是RDB(redis database)持久化(原理是将Redis在内存中的数据记录定时dump到磁盘上的RDB持久化),另一种是AOF持久化(原理是将Redis的写操作日志(“set aaa 111 " " lpush lista 1112”…)一追加的形式写入文件

区别:
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程中是fork一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制进行压缩存储
redis 发布和订阅 持久化 事务 缓存问题_第7张图片

RDB具体实现:
在这个配置文件中
vim /usr/redis/bin/redis.conf
:196
#after 900 sec (15 min) if at least 1 key changed 在15分钟之内,如果有一个key发生变化都会发生一次RDB save 900 1
#after 300 sec (5 min) if at least 10 keys changed 在5分钟之内,如果有10个key发生变化都会发生一次RDBsave 300 10
#after 60 sec if at least 10000 keys changed 在一分钟之内,如果有10000个key发生变化都会发生一次RDB save 60 10000

每秒中最多执行81000次

生成的快照文件为
The filename where to dump the DB :253 dbfilename dump.rdb 在启动redis服务的位置会生成该文件

redis 发布和订阅 持久化 事务 缓存问题_第8张图片
AOF具体实现:

vim /usr/redis/bin/redis.conf

:699 appendoly no 如果要开启aof需要修改配置为yes

:703 append only “appendonly.aof” aop写命令存储的文件

:705 aof具体配置
aof redis默认支持三种方式:

no: don’t fsync, just let the OS flush the data when it wants. Faster. 从来不执行aof 速度最快,最不安全(数据丢失时,就找不回来)

always: fsync after every write to the append only log. Slow, Safest. 每一个写命令执行完成后都把命令追加到appendonly.aof 速度最慢,最安全(数据一条都不会丢失)

everysec: fsync only one time every second. Compromise. 系统默认,即不是使用no也不使用always使用协调的方式 每一秒执行一次aof

:729 appendfsync everysec 默认的方式

优缺点:

RDP优点:
1.RDB是一个非常紧凑的文件,他保存了某个时间点的数据集,适合数据集的被备份,可以每小时保存前24小时的数据,同时每天保存过去30天的数据,这样即使出了问题也可以根据需求恢复到不同版本的数据集
2. RDB是一个紧凑单一的文件,方便传送到另一个远端数据中心,或者亚马逊s3,适用于发生灾难恢复
3. RDB在保存RDB文件时父进程要做的就是fork一个子进程,在接下来的工作全部交给子进程来做,父进程不需要再左其它的IO操作,所以RDB持久化方式可以最大化redis的性能,与AOF相比,在恢复大数据集的时候,RDB的方式会更快一些
RDB缺点:
1.由于redis的保存方式,在redis突然停止工作的话,无法做到丢失的数据最少,虽然可以配置不同的save时间点保存,但是redis想要完整保存整个数据是一个比较繁重的工作,通常都是选择5分钟或者更久完整保存一次,但是如果宕机的话这几分钟的数据就会丢失,81000次每秒的写入会损失很大。
2.RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,子进程非常耗时,可能导致redis在毫秒级内不能响应客户端的请求,如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续一秒,客户端一秒不能响应是非常恐怖的,虽然AOF也需要fork,但是你可以调节重写日志文件的频率来提高数集的耐久度

AOF的优点:
1.使用AOF会让Redis更加耐久:
使用不同的fsync策略:无fync ,每秒fync ,每次写的时候fync,
使用默认fync策略,Redis的性能依然很好(fync是后台进程处理的,主线程会尽力处理客户端请求),一旦故障,最多损失一秒的数据。
2.AOF文件是一个只进行追加的日志文件,所以不需要写入seek,,即使因为某些原因(磁盘空间满了,写的过程宕机了等)未执行完整的写入命令,也可以使用redis-check-aof工具修复这些问题,Redis可以在Aof文件体积变得过大时,自动地在后台对AOF进行重写,重写后新的AOF文件包含了当前数据集所需要的最小的命令的文件的集合。整个重写的操作绝对是安全的,在Redis创建新的AOF文件的过程中,会继续将命令追加到现有的AOF文件中,,即使重写过程中停机,现有的AOF文件也不会丢失,而一旦新AOF文件创建完毕,Reids就会从旧AOF文件切换到新的AOF文件,并且对新的AOF进行追加操作。
3.AOF文件有序地保存了对数据库执行的所有写操作,这些写入操作以Redis协议的格式保存,因此AOF文件非常容易读懂,到处AOF文件也非常简单:举个例子,如果不小心执行了FLUSHALL命令,但是只要AOF文件未被重写,AOF文件未被重写,那么只要停止服务器,移除AOF文件末尾的FLUSHALL命令,并重启Redis,就可以将数据集恢复到FLUSHALL执行状态之前

AOF缺点:
1.对于相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积。
2.根据使用的fsync策略,AOF速度会慢于RDB。一般情况下,每秒fsync的性能依然非常高,而关闭fsync可以让AOF的速度和RDB一样快,即使在高负荷之下也是如此,但是巨大的写处理时,RDB可以提供更有保证的最大延迟时间。

RDB和AOP同时开启时,默认会使用AOF:
你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整

Redis事务

事务概念:
1.事务是一个单独的隔离操作:事务中的所有命令都会序列化,按顺序的执行。事务在执行过程中,不会被其它客户端打送过来的命令请求打断。
2.事务是一个原子操作:事务中的命令要么全部执行,要么全部不执行。

事务的相关命令:
MULTI:命令用于开启一个事务,他总是返回OK。MULTI执行之后,客户端可以继续向服务器发送任意多条命令,但是不会立即被执行,而是被放到一个队列中,当EXEC命令被调用时,所有队列中的命令才会被执行。
EXEC:执行所有事务块内的命令,返回事务块内搜友命令的返回值,按命令执行的先后顺序排列,当操作被打断时,返回控制nil
DISCARD:当执行DISCARD命令时,事务会被抛弃,事务队列会被清空,并且客户端会从事务状态中退出
WATCH:命令可以为Redis事务提供check-and-set (CAS)行为,可以监控一个或者多个键,一旦其中有一个键被修改或者删除,之后的事务就不会执行,监控一致持续EXEC命令。

redis 发布和订阅 持久化 事务 缓存问题_第9张图片

redis 发布和订阅 持久化 事务 缓存问题_第10张图片
redis 发布和订阅 持久化 事务 缓存问题_第11张图片
redis 发布和订阅 持久化 事务 缓存问题_第12张图片
缓存问题:

缓存穿透:
redis 发布和订阅 持久化 事务 缓存问题_第13张图片
缓存穿透是指缓存区和数据库中都没有的数据,而用户不断发起请求,如发起id为-1的数据或者id为特别大不存在的数据,这是的用户很可能就是攻击者,攻击会导致数据库压力过大。
解决办法:
1.对查询结果为空的情况进行缓存,缓存时间短一点,该key对应的数据新增后进行清理缓存。
2.对一定不存在的key进行过滤,可以把所有的可能存在的key放到一个Bigtmap中(布隆过滤器),查询时通过该bitmap过滤

缓存击穿:

redis 发布和订阅 持久化 事务 缓存问题_第14张图片
缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力

如何避免?
设置热点数据永远不过期。加互斥锁,互斥锁参考思路如下
1)缓存中有数据,直接返回结果了
2)缓存中没有数据,第1个进入的线程,获取锁并从数据库去取数据,没释放锁之前,其他并行进入的线程会等待100ms,再重新去缓存取数据。这样就防止都去数据库重复取数据,重复往缓存中更新数据情况出现。

缓存雪崩:
redis 发布和订阅 持久化 事务 缓存问题_第15张图片
缓存雪崩是指缓存中数据大批量到过期时间,而查询数据量巨大,引起数据库压力过大甚至down机。和缓存击穿不同的是, 缓存击穿指并发查同一条数据,缓存雪崩是不同数据都过期了,很多数据都查不到从而查数据库。

如何避免?
缓存数据的过期时间设置随机,防止同一时间大量数据过期现象发生。
如果缓存数据库是分布式部署,将热点数据均匀分布在不同的缓存数据库中。
设置热点数据永远不过期。

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号