全球热门网站排名,菜单 wordpress,郑州网站建设蝶动,长沙加度网络科技有限公司Redis 的事务和 MySQL 的事务概念上是类似的#xff0c;都是把一系列操作绑定成一组#xff0c;让这一组能够批量执行。 一、Redis 的事务和 MySQL 事务的区别
1、MySQL 事务 原子性#xff1a;把多个操作打包成一个整体。#xff08;要么全都做#xff0c;要么都不做都是把一系列操作绑定成一组让这一组能够批量执行。 一、Redis 的事务和 MySQL 事务的区别
1、MySQL 事务 原子性把多个操作打包成一个整体。要么全都做要么都不做⼀致性事务执行前和执行后数据得保持相同。隔离性事务并发执行涉及到的一些问题脏读、幻读等。持久性事务中做出的修改都会存储到硬盘中。 2、Redis 的事务 弱化的原子性redis 没有 “回滚机制”只能做到这些操作 “批量执行”不能做到 “一个失败就恢复到初始状态”也就是无法保证执行成功。网上有的说 Redis 事务有原子性只是打包一起执行有的说没有原子性打包一起执行 带有回滚 —— 打包一起正确执行不保证⼀致性不涉及 “约束”也没有回滚MySQL 的一致性体现的是运行事务前和运行后结果都是合理有效的不会出现中间非法状态。事务在执行过程中如果某个修改操作出现失败就可能引起不一致的情况。不需要隔离性也没有隔离级别因为不会并发执行事务Redis 是一个单线程模型的服务器程序所有的请求 / 事务都是 “串行” 执行的。不需要持久性Redis 本身就是内存数据库数据是存储在内存中的。虽然 Redis 也有持久化机制但是否开启持久化是 redis-server 自己的事情和事务无关。 Redis 事务本质上是在服务器上搞了⼀个 “事务队列”每次客户端在事务中进行一个操作都会把命令先发给服务器放到 “事务队列” 中但并不会立即执行而是在收到 EXEC 命令后才按照顺序依次执行队列中的所有操作在 Redis 主线程中完成的主线程会把事务中的操作都执行完再处理别的客户端。
因此Redis 的事务的功能相比于 MySQL 来说是弱化很多的。只能保证事务中的这几个操作是 “连续的”不会被别的客户端 “加塞”仅此而已。 为什么 Redis 不设计成和 MySQL 一样强大呢 MySQL 的事务付出了很大的代价 在空间上需要花费更多的空间来存储更多的数据。在时间上也要有更大的执行开销。 正是因为 Redis 简单、高效的特点才能够在分布式系统中弥补一些 MySQL 不擅长的场景。 什么时候需要使用到 Redis 事务呢 如果我们需要把多个操作打包进行使用事务是比较合适的。之前在多线程中是通过加锁的方式来避免 “插队” 的而在 Redis 中直接使用事务即可。 在上面这个场景没有加锁也能解决问题。
Redis 命令里能够进行类似上图中的条件判断吗 Redis 原生命令中确实没有这种条件判断但是 Redis 支持 lua 脚本。通过 lua 脚本就可以实现上述的条件判定并且也和事务一样是打包批量执行的。 lua 脚本的实现方式是 Redis 事务的进阶版本此处对 lua 脚本不做过多的讨论。 注意如果 Redis 是按照集群模式部署的话是不支持事务的。 二、事务操作
1、MULTI 开启一个事务执行成功返回 OK。 2、EXEC 真正执行事务。 每次添加一个操作都会提示 QUEUED说明命令已经进入客户端的事务队列中。此时如果另外开一个客户端再尝试查询这几个 key 对应的数据是没有结果的 只有当真正执行 EXEC 的时候客户端才会真正把上述操作发送给服务器此时就可以获取到上述 key 的值了。 此时另一个客户端再次查询结果也是如此。 3、DISCARD
放弃当前事务此时直接清空事务队列之前的操作都不会真正执行到。 当开启事务并给服务器发送若干个命令之后服务器重启那么此时这个事务怎么办呢 此时的效果就等同于 discard。 4、WATCH
在执行事务的时候如果某个事务中修改的值被别的客户端修改了此时就容易出现数据不一致的问题。
客户端 1 先执行 客户端 2 再执行 客户端 1 最后执行 此时 key 的值是多少呢? 从输入命令的时间看是客户端 1 先执行的 set key 222客户端 2 后执行的 set key 333。但是从实际的执行时间来看是客户端 2 先执行的客户端 1 后执行的。 由于客户端 1 得是 exec 执行了才会真正执行 set key 222所以这个操作实际上更晚执行最终值就是 222. 这个时候其实就容易引起歧义。因此即使不保证严格的隔离性至少也要告诉用户当前的操作可能存在风险。watch 命令就是用来解决上述这个问题的watch 在该客户端上监控一组具体的 key看看这个 key 在事务的 multi 和 exec 之间set key 之后是否在外部被其他客户端修改了。
当开启事务的时候如果对 watch 的 key 进行修改就会记录当前 key 的 “版本号”版本号可以理解成一个整数每次修改都会使版本变大服务器来维护每个 key 的版本号情况在真正提交事务的时候如果发现当前服务器上的 key 的版本号已经超过了事务开始时的版本号就会让事务执行失败事务中的所有操作都不执行。
客户端 1 先执行 watch 本质上是给 exec 加一个判定条件。
key 进行修改从服务器获取 key 的版本号是 0记录 key 的版本号还没真的修改版本号不变
这里只是入队列但是不提交事务执行。
客户端 2 再执行 修改成功使服务器端的 key 的版本号 0 - 1
客户端 1 最后执行 exec 在执行上述事务中的命令时此处就会做出判定。对比版本发现客户端的 key 的版本号是 0服务器上的版本号是 1版本不一致说明有其他客户端在事务中间修改了 key说明事务被取消了于是真正执行 set key 222 的时候就没有真正执行。
客户端 2 执行 1watch 的实现原理
watch 的实现类似于一个 “乐观锁”不是指某个具体的锁而指的是某一类锁的特性。
乐观锁成本低加锁之前就有一个心理预期预期接下来锁冲突的概率比较低。悲观锁成本高加锁之前就有一个心理预期预期接下来锁冲突两个线程针对同一个锁加锁一个能加锁成功另一个就得阻塞等待的概率比较高。
锁冲突概率高和冲突概率低意味着接下来要做的工作是不一样的。
C Linux 中涉及到的锁 mutex / std::mutex 都是悲观锁Java synchronized 则是可以在悲观和乐观之间自适应。 5、UNWATCH
取消对 key 的监控相当于 WATCH 的逆操作。
