Redis事务

本文介绍了Redis事务的特性,包括无隔离级别、命令执行模式、事务的原子性和非原子性,以及watchkey、乐观锁和悲观锁的概念。同时讨论了Redis的持久化机制,如RDB和AOF,并比较了它们的优缺点及使用场景。
摘要由CSDN通过智能技术生成

Redis事务是一个单独的隔离操作:事务中的所有的命令都会序列化,按顺序执行。事务在执行的过程中,不会被其其他客户端发送来的命令请求所打断。Redis事务的主要作用就是串联多个命令防止别的命令插队

特点:

1.Redis事务没有隔离级别的概念

2.所有的命令在事务中,并没有直接被执行,只有发起执行命令的时候才会执行!Exec

3.Redis单条命令式保存原子性的,但是事务不保证原子性!

命令描述
multi标记一个事务的开始
exec执行所有事务块内的命令
watch key
监视一个或者多个key,如果在事务执行之前这个或者这些key被其他命令那么事务将被打断。类似乐观锁
discard取消事务,放弃执行事务块内的所有命令
unwatch取消watch命令所有key的监视
悲观锁
悲观锁 (Pessimistic Lock) , 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每 次在拿数据的时候都会上锁,这样别人想拿这个数据就会block 直到它拿到锁。 传统的关系型数据库里 边就用到了很多这种锁机制 ,比如 行锁 表锁 等, 读锁 写锁 等,都是在做操作之前先上锁
乐观锁
乐观锁 (Optimistic Lock) 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不 会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。 乐观锁适用于多读的应用类型,这样可以提高吞吐量 Redis 就是利用这种 check-and-set 机制实现事务的

redis持久化

Redis 是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中
的数据库状态也会消失。所以 Redis 提供了持久化功能!
持久化过程保存什么
1. 将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据 RDB
2. 将数据的操作过程进行保存 , 日志形式,存储操作过程,关注点在数据的操作过程
AOF

RDB方式

在指定的时间间隔内将内存中的数据集 快照 写入磁盘, 也就是行话讲的 Snapshot 快照,它恢复时是将快照文件直接读到内存里
RDB手动
save指令
命令:save
作用:手动执行一次保存操作

save指令相关配置

dbfifilename dump.rdb
说明:设置本地数据库文件名,默认值为 dump.rdb
经验:通常设置为 dump- 端口号 .rdb
dir
说明:设置存储 .rdb 文件的路径
经验:通常设置成存储空间较大的目录中,目录名称 data
rdbcompression yes
说明:设置存储至本地数据库时是否压缩数据,默认为 yes ,采用 LZF 算法 压缩
经验:通常默认为开启状态,如果设置为 no ,可以节省 CPU 运行时间,但会使存储的文件变大(巨 大)
rdbchecksum yes
说明:设置是否进行 CRC64 算法 RDB 文件格式校验, 该校验过程在写文件和读文件过程均进行
经验:通常默认为开启状态,如果设置为 no ,可以节约读写性过程约 10% 时间消耗,但是存储一定的数据损坏风险
 
save 指令工作原理 ( 单线程任务执行序列 )
客户端 1 127.0.0.1:6379>set key1 value1
客户端 2 127.0.0.1:6379>set key2 value2
客户端 3 127.0.0.1:6379>save
客户端 4 127.0.0.1:6379>get key
redis 数据库执行 4 此指令顺序 ===> set set save get
注意: save 指令的执行会阻塞当前 Redis 服务器,直到当前 RDB 过程完成为止,有可能会造成长时间阻 塞,线上环境不建议使用
bgsave 指令
命令 : bgsave
作用 :手动启动后台保存操作,但不是立即执行
bgsave 指令工作原理
注意: bgsave 命令是针对 save 阻塞问题做的优化。 Redis 内部所有涉及到 RDB 操作都采用 bgsave 的方式,save 命令可以放弃使用
Fork
Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等) 数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程

RDB自动

配置 : save second changes
作用 : 满足限定时间范围内 key 的变化数量达到指定数量即进行持久化
参数 :
                second:监控时间范围
                changes:监控key 的变化量
位置 : conf 文件中进行配置
注意:
save 配置要根据实际业务情况进行设置,频度过高或过低都会出现性能问题,结果可能是灾难性的
save 配置中对于 second changes 设置通常具有互补对应关系,尽量不要设置成包含性关系 save配置启动后执行的是 bgsave 操作
RDB 优点
RDB 是一个紧凑压缩的二进制文件,存储效率较高
RDB 内部存储的是 redis 在某个时间点的数据快照,非常适合用于数据备份,全量复制等场景
RDB 恢复数据的速度要比 AOF 快很多
RDB 节省磁盘空间
RDB 缺点
Fork 的时候,内存中的数据被克隆了一份,大致 2 倍的膨胀性需要考虑
虽然 Redis fork 时使用了 写时拷贝技术 , 但是如果数据庞大时还是比较消耗性能
RDB 方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据
Redis 的众多版本中未进行 RDB 文件格式的版本统一,有可能出现各版本服务之间数据格式无法兼容现象
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值