推荐几个好的网站,正邦品牌设计,深圳代理记账费用,免费logo设计无水印目录 一、Redis 事务 vs MySQL事务
二、Redis 事务的执行原理
2.1、执行原理
2.2、Redis 事务设计这么简单#xff0c;为什么不涉及成 MySQL 那样强大呢#xff1f;
三、Redis 事务的使用
3.1、使用场景
3.2、具体演示
开启/执行/放弃事务
watch 监控
watch 实现原理…目录 一、Redis 事务 vs MySQL事务
二、Redis 事务的执行原理
2.1、执行原理
2.2、Redis 事务设计这么简单为什么不涉及成 MySQL 那样强大呢
三、Redis 事务的使用
3.1、使用场景
3.2、具体演示
开启/执行/放弃事务
watch 监控
watch 实现原理
小结 一、Redis 事务 vs MySQL事务 我们熟知的 MySQL你还记得她的事务特性么
原子性将多个操作打包成一个整体要么全都执行成功要么一个都不执行一旦执行出错立刻回滚如初.一致性事务执行前后通过约束和回滚机制保证数据合理. 例如我去银行给 张三 转账 1 元钱那么我的卡里就会减少 1 元张三的卡里就会增加 1 元不能增加 100 元。持久性事务做出的修改都会存储到硬盘上不会随着服务器重启而丢失.隔离性事务并发执行涉及到的一些问题.
Redis 的事务和 MySQL 相比就像一个“弟弟”~
原子性Redis 的事务到底有没有在原子性存在争议因为从 Redis 的角度理解就是“把多个操作打包到一起要么全都执行要么全都不执行”也就是说这里如果中途执行失败那就失败吧不会有像 MySQL 那样回滚的操作也因此网上有人一部分人说 redis 事务有原子性一部分说没有原子性都对但是要看从那个角度出发了~.不具备一致性redis 没有约束和回滚事务执行一旦出错就可能导致不一致的情况.不具备持久性Redis 本身就是内存数据库数据是存储在内存中的. 虽然 Redis 也有持久化机制但是这里的持久化机制和事务没有什么直接关系.不具备隔离性Redis 是一个单线程模型的服务器程序所有的请求 / 事务都是 “串行” 执行的. 二、Redis 事务的执行原理 2.1、执行原理
Redis 事务的主要意义就是为了 “打包” 避免其他客户端的命令插队到其中那他具体是通过什么实现的呢Redis 实现事务是引入了队列每一个客户端都有开启事务的时候客户端输入的命令就会发给服务器然后进入都这个队列中此时并不会立即执行当收到 “执行事务” 命令的时候就会把队列中的这些任务按照顺序依次执行这里是由 Redis 主线程执行的他会把事务中的操作执行完再去执行其他客户端.
举个例子这就像是你去做核酸检测但是核酸检测是早上 7 点开始但是你 6 点就来了还发现已经有一些人在这里排成长队所以这个时候你只能在去后面排队不能插队等到核酸检测开始并且前面的人都检测完了才轮到你~ 2.2、Redis 事务设计这么简单为什么不涉及成 MySQL 那样强大呢
MySQL 的事务之所以能设计的这么强大原子性、一致性....背后是付出了很多代价的~
空间上要花费跟多的空间来存储更多的数据例如 MySQL 事务执行中途出错引发的回滚机制这种回滚机制也是需要花费空间去记录每条执行的指令是什么才能进行回滚的.时间上也要有更大的执行开销比如 MySQL 事务的持久化机制是存储在硬盘上的操作缓慢再例如 MySQL 中事务遇到冲突是进行加锁加锁也是需要开销的涉及到用户态到内核态的转化而且加锁就有可能产生锁竞争一竞争就会加锁排队一排队就不知道什么时候释放锁了~
也正因如此Redis 才有了上场的机会。 三、Redis 事务的使用 3.1、使用场景
如果需要把多个操作打包进行使用事务就是比较合适的~
比如说以前春运咱们在网上抢火车票的场景、秒杀...
这里以抢火车票的场景为例
假设现在有大量的用户都在同一时间段开始抢票也就是说有多个 Redis 客户端执行执行抢票操作如下
获取仓库中剩余的票数;
if(剩余的票数 0) {下单成功;商品数量--;
}
这里如果不加任何限制就有可能引发 “线程安全” 问题~ 以前咱们解决线程安全问题都是通过加锁排队来避免 “插队” 的而 redis 这里不加锁也能解决上述问题直接使用事务即可如下
开启事务
get count
if count 0decr count
执行事务 PsRedis 原生的命令中是没有上述这种判断的但是 Redis 支持 lua 脚本通过 lua 脚本就可以实现上述的 条件判定并且也和事务一样是打包批量执行的. 确实redis 的事务使用场景没有 mysql 事务那么多并且 redis 如果是按照集群模式部署是不支持事务的. 3.2、具体演示
redis 的事务是通过以下命令进行控制的
multi 开启事务读作 “猫体”
exec 执行事务
discard 放弃当前事务
watch 监控某个 key 是否在事务执行之前发生变化必须搭配事务使用
unwatch 放弃监控 开启/执行/放弃事务
开启事务执行以下命令: 此时开启另一个客户端查看这几个 key 会发现这几个 key 并没有被赋值说明此时还没有执行事务).如下 如果放弃事务就相当于什么也没有发生如下 如果使用 exec就会按顺序执行事务如下 watch 监控
watch 就是用来监控某个 key 是否在事务执行之前发生改变但必须搭配事务来使用.
如下用 watch 监控 key1开启事务并在执行事务之前另一个客户端对 key1 进行修改如下 执行事务后发现 key 在外部由修改会返回 nil 表示事务什么都不会执行如下 watch 实现原理
watch 的实现类似于一个 “乐观锁”.
乐观锁不是某个具体的锁而是指某一类锁的特性加锁之前就会有一个心里预期预期接下来锁冲突的概论比较低就像是有些同学考试前觉得自己平时学的很扎实因此考试前就轻松一些少复习一点~
redis 的 watch 就相当于基于 “版本号” 这样的机制实现 “乐观锁”。
当执行 watch key 的时候就会给 key 安排一个 版本号版本号可以理解成一个“整数”每次在修改 key 的时候版本号都会 “变大” 这个变大是没有规律的不是每次都增长1然后在执行 事务 的时候就会做出判定判断当前这个 key 的版本号和最初 watch 的时候记录的版本号是否一致~
如果一致说明当前 key 在事务开启到最终执行这个过程中没有别的客户端修改才能真正的执行事务.如果不一致就说明 key 在其他客户端修改过了因此就直接丢弃事务中的所有操作最后返回 nil. Ps这样的设定在 CAS 的 ABA 问题中也涉及到过思想方法和实现上都是非常相似的例如 CAS 实现自旋锁就类似版本号设定的实现. 小结 重在学习思想而不是理论很多思想都是触类旁通的当我们未来遇到某一类问题的时候就可以回想起当时解决问题的思想方法迎刃而解~
