三.Redis入门指南--Redis特性

一.redis 事务

首先进入Redis

#查看容器
docker ps
#进入redis容器
docker exec -it 容器ID bash
#选择连接的redis ip 和端口 我本地用的16379端口
redis-cli -h 127.0.0.1 -p 16379 
#输入用户名和密码  配置文件中的
auth mima
#查找key
key [key规则]
#删除key
del [key]

在这里插入图片描述

1.事务概念

1.1什么是事务

单个redis命令的执行是原子性的,但redis并没有在事务上增加任何维持原子性的机制,所以redis事务的执行并不是原子性的。事务可以理解为一个打包的批量执行脚本,但批量指令并非原子化的操作,redis中并没有回滚的机制,也就是说中间某条指令的失败不会导致前面已做指令的回滚,也不会造成后续的指令不做。

1.2事务命令

一共五个命令:
开启事务:multi
执行事务:exec
取消事务:discard:就像mysql中用begin开启事务、用commit结束事务一样。redis中是用multi开启事务,用exec执行命令。如果在exec之前你不想执行事务了,可以用discard取消当前事务。
监控:watch
取消监控:unwatch
事务的原理:当执行multi命令会开启事务,那么所有的命令会加入到事务队列暂存,不会真正的直接执行,如果遇到exec就会把队列中的命令依次执行-提交事务,即使其中有命令执行失败了,也不会影响其他命令的执行结果-不回滚,但遇到discard就会放弃执行队列中的命令-取消事务。

在这里插入图片描述

1.3 实操
mutli #开启事务

看到TX表示开启事务了,可以做后续的操作
在这里插入图片描述

set name xuxu
set desription cool
set age 18

在这里插入图片描述
之后执行exec

exec #提交事务
get name #返回name的值
get decription #返回描述的值 单词写错 将就了
get age #返回年龄的值

结果如下:
在这里插入图片描述
此时我们到redis可视化工具上看,将key value成功插入
在这里插入图片描述执行discard命令

discard #取消事务,开启multi后的所有命令都会被取消
get name #返回空值
get age #返回空值

在这里插入图片描述
此时再执行exec就会报错
在这里插入图片描述

1.4事务为什么不支持回滚

先来看看redis事务执行异常的情况,再说为什么不支持回滚

1.语法错误带着事务执行异常,导致事务取消

127.0.0.1:16379> set s1 1111 #设置是s1值
OK
127.0.0.1:16379> set s2 2222 #设置s2的值
OK
127.0.0.1:16379> get s1
"1111"
127.0.0.1:16379> get s2
"2222"
127.0.0.1:16379> 
127.0.0.1:16379> multi #开启事务
OK
127.0.0.1:16379(TX)> set s1 11 #设置值
QUEUED
127.0.0.1:16379(TX)> sets s2 22 #设置值 但语法报错
(error) ERR unknown command `sets`, with args beginning with: `s2`, `22`,  
127.0.0.1:16379(TX)> exec #执行事务,但前面语法有错误,所以此事务取消
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:16379> get s1
"1111"
127.0.0.1:16379> get s2 #此时s1和s2的值在事务中未改变
"2222"
127.0.0.1:16379> 

2.运行时错误(redis类型错误)导致事务异常
开启事务,设置s1的值为11,s2的值为22,开启事务,再设置s1的值为1111,但在设置s2时,将其类型作为list存入,此时运行时报错,导致事务提交失败,但此时事务并未回滚,而是跳过错误命令继续执行,此时s1的值改变,s2保留原值。

127.0.0.1:16379> set s1 11
OK
127.0.0.1:16379> set s2 22
OK
127.0.0.1:16379> multi #开启事务
OK
127.0.0.1:16379(TX)> set s1 1111
QUEUED
127.0.0.1:16379(TX)> lpush s2 2222 #类型不一致,s2为字符串,在这儿作为list来操作
QUEUED
127.0.0.1:16379(TX)> exec #提交并执行事务报错
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:16379> get s1 #修改成功
"1111"
127.0.0.1:16379> get s2 #修改失败
"22"
127.0.0.1:16379> 

总结:redis为什么不支持事务回滚?
多数事务失败是由语法错误或者数据类型错误导致的,语法错误在命令入队就进行检测,而类型错误是在执行时检测的,Redis为提升性能而采用这种简单的事务,不同于关系型数据库。

1.5:watch和unwatch命令

1.watch命令
上述的redis操作的事务是不支持回滚的,如果要让其回滚,这就需要watch命令;注:watch在mutli命令之前使用
watch的作用: 监控一个值是否发生变化,如果没有发生变化,他会执行事务队列中的命令,提交事务;如果发生变化,将不会执行事务中的任何命令,同时事务回滚。最后无论是否回滚,Redis都会取消事务前的WATCH命令。
在这里插入图片描述

验证: 在事务开始前,使用watch命令监控s1,之后修改s1为111111,mutli开始事务修改s2的值222222,执行EXEC,返回nil,说明事务回滚;再查看s2的值有没有被改变

127.0.0.1:16379> set s1 11111 #设置s1的值
OK
127.0.0.1:16379> set s2 22222 #设置s2的值
OK 
127.0.0.1:16379> get s1
"11111"
127.0.0.1:16379> get s2
"22222"
127.0.0.1:16379> watch s1 #监控s1的值
OK
127.0.0.1:16379> set s1 11111111 #修改s1的值
OK
127.0.0.1:16379> multi #开启事务
OK
127.0.0.1:16379(TX)> set s2 2222222 #修改s2的值
QUEUED
127.0.0.1:16379(TX)> exec #执行事务 发送错误  事务回滚
(nil)
127.0.0.1:16379> get s1  #获取s1的值 发生了改变
"11111111"
127.0.0.1:16379> get s2 #获取s2的值 未改变
"22222"
127.0.0.1:16379> 

2.unwatch命令
unwatch命令是取消监控,在事务开启前对监控的对象取消监控,事务就不会回滚了

在这里插入图片描述

验证

127.0.0.1:16379> set a1 1
OK
127.0.0.1:16379> set a2 2
OK
127.0.0.1:16379> watch a1 #监控a1
OK
127.0.0.1:16379> set a1 11 #改变a1的值
OK
127.0.0.1:16379> unwatch #取消监控
OK
127.0.0.1:16379> multi #开启事务
OK
127.0.0.1:16379(TX)> set a1 111
QUEUED
127.0.0.1:16379(TX)> set a2 222
QUEUED
127.0.0.1:16379(TX)> exec #执行事务成功
1) OK
2) OK
127.0.0.1:16379> get a1
"111"
127.0.0.1:16379> get a2 #修改a2的值成功
"222"
127.0.0.1:16379> 

二.Redis的持久化-rdb和aof

Redis是一个键值对数据量服务器,由于Redis是内存服务器,那么有很多内存的特点,例如断电,那么服务器中的数据也将消失不见,那么就需要一种方法将数据从内存中写到磁盘,这一过程称为数据持久化。
Redis持久化有两种方式

1.RDB和AOF

1.1:RDB

rdb持久化机制,是对redis中的数据执行周期性的持久化。
RDB优缺点
1.RDB会生成多个数据文件,每个数据文件都代表了某一时刻中redis的数据,这种多个数据文件的方式,适合做冷备,可以将这种完整的数据文件发送到远程的安全存储上去。
2.RDB对redis对外提供的读写服务,影响非常小,可以让redis 高性能 ,因为redis主进程只需要一个fork一个子进程,让子进程执行磁盘IO操作来进行RDB持久化即可。
3.相对于AOF持久化机制来说,直接基于RDB数据文件来重启和回复redis进程,更加快速。
4.如果想要在Redis故障时,尽可能少的丢失数据,那么RDB没有AOF好。一般来说,RDB数据快照文件,都是每隔5分钟,或者在更长时间生成一次,这个时候就得接受一点redis进程宕机,那么会丢失最近5分钟的数据。
5.RDB每次在fork子进程来执行RDB快照数据文件生成的时候,如果数据文件特别大,可能会导致对客户端提供的服务暂停数毫秒,甚至数秒。
怎么开启

save ""
# save 900 1        #至少在900秒的时间段内至少有一次改变存储同步一次
# save xxx
# save 60 10000

1.2:AOF

AOF优缺点
1.AOF可以更好的保护数据不丢失,一般AOF会每隔1秒,通过后台线程执行fsync操作,最多丢失一秒钟的数据。
2.AOF日志文件以append-only模式写入,所以没有任何磁盘寻址的开销,写入性能非常高,而且文件不容易损坏,即使文件尾部损坏,也容易修复。
3.AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。因为在rewrite log的时候,会对其中的指令进行压缩,创建出一份需要恢复数据的最小日志出来,在创建新日志文件的时候,老的日志文件还是照常写入。当新的merge后的日志文件ready的时候,再交换老日志文件出来。
4.AOF日志文件的命令通过非常可读的方式进行记录,这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空所有数据,只要这个时候后台的rewrite还没有发生,那么就可以立即拷贝AOF文件,将最后一条flushall命令删了。然后再将AOF文件放进去,就可以通过恢复机制,自动恢复所有数据。
5.对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大。
6.AOF开启后,支持的写QPS会比RDB支持的QPS低,因为AOF一般会配置成每秒fsync一次日志文件,当然,每秒一次fysnc,性能也还是非常高的。(如果实时写入,那么QPS会大降,redis性能会大大降低)
7.AOF 这种较为复杂的基于命令日志 / merge / 回放的方式,比基于 RDB 每次持久化一份完整的数据快照文件的方式,更加脆弱一些,容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug,因此每次 rewrite 并不是基于旧的指令日志进行 merge 的,而是基于当时内存中的数据进行指令的重新构建,这样健壮性会好很多。
怎么开启

appendonly yes        #yes 开启,no 关闭

# appendfsync always  #每次有新命令时就执行一次fsync 

appendfsync everysec  #每秒 fsync 一次 ,这里我们启用 everysec

# appendfsync no      #从不fsync(交给操作系统来处理,可能很久才执行一次fsync)
1.3:怎么选择持久化方式

1.完全不在乎数据丢失:关闭持久化,保持极佳的性能。
2.对数据丢失不敏感,能接受一段时间的数据丢失:选择RDB.
3.对数据丢失敏感,需要尽可能避免丢失数据:混合持久化。用AOF来保证数据不丢失,作为恢复的第一选择;用RDB来做不同程度的冷备。在AOF文件丢失或损坏不可用的时候,使用RDB来快速恢复数据。

三.Redis的淘汰策略

1.淘汰策略的基本概念

redis过期策略: 定期删除+惰性删除
定期删除: 指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key,检查其是否过期,如果过期就删除。
注:这里不是每隔100ms就遍历所有设置过期时间的key,而是随机抽取一些key来检查和删除的。
但定期删除可能会导致很多过期的key到了时间并没有被删除掉,这时候就需要惰性删除 。意思就是当你获取某个key的时候,redis会检查一下,这个key如果设置了过期时间那么是否过期了?如果过期了此时就会删除,不会返回任何东西。
但如果定期删除漏掉了很多过期key,也没及时查,也就没走惰性删除。这时大量的key堆积在内存里,导致redis的内存耗尽了,此时就需要走:内存淘汰机制
内存淘汰机制 - - -一共6个
1.noeviction:当内存不足以容纳新写入数据时,新写入操作会报错。
2.allkeys-lru:尝试回收最少使用的键,使新添加的数据有空间存放,这个最常用的。
3.volatile-lru:当内存不足以容纳写入新数据时,在设置了过期时间的键空间中,移除最近最少使用的key
4.allkeys-random:当内存不足以容纳新的写入数据时,在键空间中,随机移除某个key。
5.volatile-random:当内存不足时,在设置了过期时间的键空间中,随机移除 某个key。
6.volatile-ttl:当内存不足时,在设置了过期时间的键空间中,有更早过期时间 的key会优先移除。

2.淘汰策略配置

2.1:最大内存配置

修改配置redis.windows.conf,修改maxmemory,放开注释,根据情况设置大小

maxmemory <bytes
2.2配置淘汰策略

修改配置redis.window.conf ,修改maxmemory-policy ,放开注释,按情况修改策略

maxmemory-policy noeviction		#noeviction 为默认的策略,根据情况修改
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
要排除以`/api/`开头的请求,您可以使用Ant路径匹配模式来配置`spring.session.redis.filter-dispatcher-types`属性。具体来说,您可以配置`spring.session.redis.filter-dispatcher-types`属性,使其不拦截`/api/**`路径下的请求。 例如,以下配置将排除以`/api/`开头的所有请求: ``` spring.session.redis.filter-dispatcher-types=REQUEST,ASYNC spring.session.redis.servlet.filter.enabled=false spring.session.store-type=redis spring.session.redis.flush-mode=on_save spring.session.redis.namespace=spring:session spring.session.redis.cleanup-cron=0 * * * * * spring.session.redis.save-mode=on_set_attribute spring.session.redis.redis-url=redis://localhost:6379 spring.session.redis.redis-password=password spring.session.redis.redis-sentinel-master-id=mymaster spring.session.redis.redis-sentinel-nodes=sentinel://localhost:26379,sentinel://localhost:26380,sentinel://localhost:26381 spring.session.redis.redis-sentinel-password=password spring.session.redis.redis-cluster-nodes=localhost:6379,localhost:6380,localhost:6381 spring.session.redis.redis-cluster-max-redirects=3 spring.session.redis.redis-properties.ssl=true spring.session.redis.redis-properties.ssl-truststore=classpath:redis.truststore spring.session.redis.redis-properties.ssl-truststore-password=redispassword spring.session.redis.redis-properties.ssl-keystore=classpath:redis.keystore spring.session.redis.redis-properties.ssl-keystore-password=redispassword spring.session.redis.redis-properties.useSsl=true spring.session.redis.redis-properties.sslProtocols=TLSv1.2,TLSv1.3 spring.session.redis.redis-properties.sslCipherSuites=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 spring.session.redis.redis-properties.sslProvider=JDK spring.session.redis.redis-properties.sslEnableEndpointIdentification=true spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.session.SessionAutoConfiguration ``` 在以上配置中,我们使用了Ant路径匹配模式配置`spring.session.redis.filter-dispatcher-types`属性,使其不拦截`/api/**`路径下的请求。注意,我们也排除了Spring Boot自动配置的会话管理,因为我们已经使用了Spring Session Redis进行会话管理。 请注意,这只是一个示例配置,您需要根据您的具体需求进行修改。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值