平面设计类网站什么颜色好,兴义网站制作,安溪网站开发,alexa排名文章目录 前言事务的特性Redis事务的执行原理Redis中使用事务WATCH UNWATCH实现乐观锁 前言
前面我们学习 MySQL 的时候#xff0c;肯定也学习了事务。事务是什么#xff1f;给大家举个例子#xff1a;假如我给朋友微信转账#xff0c;我给他转了 100 块钱#xff0c;当我… 文章目录 前言事务的特性Redis事务的执行原理Redis中使用事务WATCH UNWATCH实现乐观锁 前言
前面我们学习 MySQL 的时候肯定也学习了事务。事务是什么给大家举个例子假如我给朋友微信转账我给他转了 100 块钱当我输入完成密码了之后我的微信余额减了 100但是这时我的微信突然没信号了换句话就是微信服务器突然挂了当微信服务器重新启动之后我问我那个朋友 100 块钱收到了没他说没有我就去看我的微信余额发现 100 块钱扣掉了那么这时候就出现问题了我的微信余额减少了但是朋友的微信余额没有增加。遇到这种问题该如何解决呢那就是使用事务事务中的语句要么全部执行要么全部不执行。Redis 中也有事务这个概念但是和 MySQL 的事务是有区别的。
事务的特性
前面学习的 MySQL 事务有四种特性ACID
原子性Atomicity事务中的全部操作在数据库中是不可分割的要么全部完成要么均不执行。一致性Consistency几个并行执行的事务其执行结果必须与按某一顺序串行执行的结果相一致。隔离性Isolation事务的执行不受其他事务的干扰事务执行的中间结果对其他事务必须是透明的。持久性Durability对于任意已提交事务系统必须保证该事务对数据库的改变不被丢失即使数据库出现故障。
上面是 MySQL 事务的特性Redis 事务对比于 MySQL 事务而言那真的就是一句话没有可比性。
原子性是事务中的操作要么全部执行要么一个都不执行。当事务中的某个操作出现错误的时候就会将之前的操作进行回滚回滚到事务开启前的状态只有操作全部正确执行的时候才不会发生回滚。但是对于我们的 Redis 来说如果事务中的操作出现了错误之后redis 只会报错然后继续执行事务后面的操作而不会发生回滚。那么 Redis 的这种操作可以称作是原子性吗其实也是有的但是这种性质叫做弱原子性也可以说 Redis 不具有原子性大家对于原子性的定义是有歧义的所以对于 Redis 是否具有原子性也是存在歧义的。
一致性是指在事务开始之前和事务结束以后数据库的完整性没有被破坏。因为 Redis 的事务不具有回滚的功能所以也就无法保证事务的一致性也就是说 Redis 不具有一致性。
持久性是指事务的操作对于数据库的改变是永久的而由于我们的 Redis 操作数据都是在内存中的内存中的数据是易失的不具有持久性所以 Redis 不具有持久性。
隔离性是指多个事务之间的操作是互不影响的而我们的 Redis 是单线程模型的服务器程序所以也就不存在多个事务同时执行的情况就不存在所谓的隔离性特性。
啊既然 Redis 的事务 ACID 特性都没有那么 Redis 的事务是干嘛的啊其实 Redis 事务的主要功能就是为了“打包”将一个客户端发送的事务之内的操作放在一起按照顺序执行防止被其他客户端发送来的请求命令插队、干扰。
Redis事务的执行原理
Redis 实现事务引入了队列当客户端开启事务的时候接下来输入的命令 redis 服务器不会立即执行这些命令而是会将这些命令放入这个队列中这个队列是每个客户端都对应的有一个。只有当遇到执行事务这个命令的时候队列中的命令才会依次执行而这个队列中的命令只有全部执行完才会执行其他客户端对应的队列中的命令。
那么为什么 Redis 的事务搞得这么简单而不是像 MySQL 那样功能齐全呢MySQL 的事务功能齐全那是需要付出代价的需要付出更多的空间和时间而 Redis 又以快著称因为 redis 操作的对象是内存内存的价格比硬盘高不少所以完善 redis 的事务功能就以为需要牺牲速度和空间那这样还不如直接使用 MySQL。
Redis中使用事务
在 redis 中实现事务需要依赖 MULTI、EXEC和DISCARD命令。
MULTI开启事务EXEC执行事务DISCARD丢弃事务
现在一个客户端中开启事务并且向队列中添加一些命令但是不执行事务。再开启一个窗口查看事务中的操作是否执行
127.0.0.1:6379 keys *
(empty array)
127.0.0.1:6379 MULTI
OK
127.0.0.1:6379 set key1 111
QUEUED
127.0.0.1:6379 set key2 222
QUEUED
127.0.0.1:6379 set key3 333
QUEUED
127.0.0.1:6379127.0.0.1:6379 get key1
(nil)
127.0.0.1:6379 get key2
(nil)
127.0.0.1:6379 get key3
(nil)然后执行事务再看是否执行操作
127.0.0.1:6379 EXEC
1) OK
2) OK
3) OK使用 EXEC 执行事务之后返回的是事务中的每个操作的返回值
127.0.0.1:6379 get key1
111
127.0.0.1:6379 get key2
222
127.0.0.1:6379 get key3
333上面就是一个完整的事务那么如果事务中的操作出现了错误会发生什么
127.0.0.1:6379 MULTI
OK
127.0.0.1:6379 set key4 444
QUEUED
127.0.0.1:6379 setget key5 555
(error) ERR unknown command setget, with args beginning with: key5, 555,
127.0.0.1:6379 set key5 555
QUEUED
127.0.0.1:6379 EXEC
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379 get key4
(nil)
127.0.0.1:6379 get key5
(nil)
127.0.前面不是说了 redis 事务中的操作出现了问题不是不会发生回滚吗这里为什么事务中的操作都没有执行呢其实对于 redis 事务是否回滚取决于错误发生的类型如果发生错误的类型是编译时异常也就是命令错误时就会发生回滚运行时异常则不会发生回滚
127.0.0.1:6379 MULTI
OK
127.0.0.1:6379 set key4 nihao
QUEUED
127.0.0.1:6379 INCR key4
QUEUED
127.0.0.1:6379 set key5 555
QUEUED
127.0.0.1:6379 EXEC
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
127.0.0.1:6379 get key4
nihao
127.0.0.1:6379 get key5
555这里 key4 不是 intstr 类型所以执行 INCR 自增的时候就会发生错误但是由于这里的错误类型是运行时异常所以事务就不会发生回滚。
然后看看丢失当前事务的操作
127.0.0.1:6379 MULTI
OK
127.0.0.1:6379 set key6 666
QUEUED
127.0.0.1:6379 set key7 777
QUEUED
127.0.0.1:6379 DISCARD
OK
127.0.0.1:6379 get key6
(nil)
127.0.0.1:6379 get key7
(nil)这是 DISCARD 丢失事务的实现。如果在开启了事务并且向服务器发送了若干命令之后服务器突然重启了。服务器重启也就意味了内存中的数据都丢失了那么事务对应的队列中的数据也就丢失了这时候该怎么办呢其实这时就相当于执行了 DISCARD 丢弃事务的操作。
WATCH UNWATCH实现乐观锁
假设在事务开始的过程执行之前其他客户端对数据进行了修改而当前客户端事务中也会对这个数据进行修改但是对于这个数据修改多次是不允许的那么在开启事务之后执行事务之前如何判断在这个事务中要使用到的数据已经被修改了呢
这就需要使用到 WATCH 命令和 UNWATCH 命令了。通过使用 WATCH key 就可以监视这个 key当监视了这个 key 之后如果在事务中需要修改这个 key 之前这个 key 已经被修改了那么事务就会相当于执行 DISCARD 命令丢弃当前事务。
先开启事务并向 redis 服务器发送几个命令但是不执行然后再开启一个窗口修改 watch 监视的key
127.0.0.1:6379 keys *
(empty array)
127.0.0.1:6379 set key1 111
OK
127.0.0.1:6379 WATCH key1
OK
127.0.0.1:6379 MULTI
OK
127.0.0.1:6379 set key1 333
QUEUED127.0.0.1:6379 set key1 222
OK执行事务
127.0.0.1:6379 EXEC
(nil)
127.0.0.1:6379 get key1
222可以看到 key1 最终的结果是另一个窗口修改的 key1 的值另一个窗口修改的操作是早于当前窗口事务的修改的操作的按理来说key1 的值应该是事务中修改的 key1 的值结果却相反说明当前窗口的事务中的操作没有执行事务被丢弃了。
使用 UNWATCH 可以接触 WATCH 对于 key 的监视。
这个 WATCH 命令就相当于我们前面学习多线程中的加乐观锁的操作乐观锁假设在大多数情况下多个线程或事务之间不会发生冲突因此在读取数据时不会上锁。相反乐观锁会在更新数据时判断在此期间数据是否被其他线程或事务修改过。
与乐观锁相对应的就是悲观锁悲观锁总是假设最坏的情况即认为数据在处理过程中总是会被其他线程或事务修改因此在数据处理开始之前就先对数据进行锁定。
乐观锁相对于悲观锁更轻量。WATCH 的执行流程大概就是在事务中要修改监视的值时先判断当前key的值是否和使用 WATCH key 监视key的时候的值相同如果相同就允许修改不同则 DISCARD。这样虽然可以但是又会发生 ABA 问题就是这个值被修改过了只不过在我判断之前这个值又被改了回来当出现这种情况的时候也是会出现问题的所以 redis 的 WATCH 乐观锁的实现就是根据版本号来判断的当使用 WATCH key 监视 key 的时候就会为这个 key 定义一个版本号当对这个 key 进行修改的时候版本号就会加上或者减去一个值要加每次修改版本号都是加减版本号则是减不会出现这次修改版本号变大下次修改版本号变小的情况所以通过版本号的操作就很好的解决了 ABA 问题。
WATCH 命令只针对于事务来说
