Redis-11使用 watch 命令监控事务
文章目录
概述
在 Redis 中使用 watch 命令可以决定事务是执行还是回滚。
一般而言,可以在 multi 命令之前使用 watch 命令监控某些键值对,然后使用 multi 命令开启事务,执行各类对数据结构进行操作的命令,这个时候这些命令就会进入队列。
当 Redis 使用 exec 命令执行事务的时候,它首先会去比对被 watch 命令所监控的键值对,
- 如果没有发生变化,那么它会执行事务队列中的命令,提交事务;
- 如果发生变化,那么它不会执行任何事务中的命令,而去事务回滚。
无论事务是否回滚 , Redis 都会去取消执行事务前的 watch 命令
Redis watch流程
流程如下:
Redis 参考了多线程中使用的 CAS (比较与交换, Compare And Swap ) 去执行的。在
数据高并发环境的操作中,我们把这样的一个机制称为乐观锁.
ABA问题
先简要论述其操作的过程:
当一条线程去执行某些业务逻辑,但是这些业务务逻辑操作的数据可能被其他线程共享了,这样会引发多线程中数据不一致的情况。为了克服这个问题,首先,在线程开始时读取这些多线程共享的数据,并将其保存到当前进程的副本中,我们称为旧值( old value), watch 命令就是这样的一个功能 。
然后,开启线程业务逻辑,由 multi 命令提供这一功能。在执行更新前,比较当前线程副本保存的旧值和当前线程共享的值是否一致,如果不一致,那么该数据己经被其他线程操作过,此次更新失败。为了保持一致,线程就不去更新任何值,而将事务回滚:否则就认为它没有被其他线程操作过,执行对应的业务逻辑, exec 命令就是执行“类似”这样的一个功能 。
注意,“类似”这个字眼,因为不完全是,原因是 CAS 原理会产生 ABA 问题。所谓ABA 问题来自于 CAS 原理的一个设计缺陷,它可能引发 ABA 问题
在处理复杂运算的时候,被线程 2 修改的 X 的值有可能导致线程1的运算出错,而最后线程 2 将 X 的值修改为原来的旧值 A,那么到了线程 1运算结束的时间顺序 T6,它将j检测 X 的值是否发生变化,就会拿旧值 A 和 当前的 X 的值 A 比对 , 结果是一致的, 于是提交事务,然后在复杂计算的过程中 X 被线程 2 修改过了,这会导致线程1的运算出错。
在这个过程中,对于线程 2 而言 , X 的值的变化为 A->B->A,所以 CAS 原理的这个设计缺陷被形象地称为“ABA 问题”。
仅仅记录一个旧值去比较是不足够的,还要通过其他方法避免 ABA 问题。常见的方法
如 Hibernate 对缓存的持久对象( PO )加入字段段 version 值,当每次操作一次该 PO,则version=version+ 1 , 这样采用 CAS 原理探测 version 宇段 , 就能在多线程的环境中,排除ABA 问题,从而保证数据的一致性。
Redis 在执行事务的过程中 , 并不会阻塞其他连接的并发,而只是通过 比较 watch 监控的键值对去保证数据的一致性 , 所 以 Redis 多个事务完全可 以在非阻塞的多线程环境中井发执行,而且 Redis 的机制是不会产生 ABA 问题的, 这样就有利于在保证数据一致的基础上 , 提高高并发系统的数据读/写性能。
使用watch成功提交的事务的案例
时刻 | 客户端 | 说明 |
---|---|---|
T1 | set key1 value1 | 初始化 key1 |
T2 | watch key1 | 监控 key1 的健值对 |
T3 | multi | 开启事务 |
T4 | set key2 value2 | 设置 key2 的值 |
T5 | exec | 提交事务, Redis会在这个时间点检测 key1 的值在 T2 时刻后,有没有被其他命令修改泣,如果没有 , 则提交事务去执行 |
127.0.0.1:6379> FLUSHDB OK 127.0.0.1:6379> SET key1 value1 OK 127.0.0.1:6379> WATCH key1 OK 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET key2 value2 QUEUED 127.0.0.1:6379> EXEC 1) OK 127.0.0.1:6379>[/code]
这里我们使用了 watch 命令设置了 一个 key1 的监控 , 然后开启事务设置 key2 , 直至exec 命令去执行事务. 如果在当前会话中修改key1的值,也是可以成功的。
使用watch回滚的事务的案例
时刻 | 客户端1 | 客户端2 | 说明 |
---|---|---|---|
T1 | set key1 value1 | — | 客户端 1 :返回 OK |
T2 | watch key1 | — | 客户端 1 :监控 key1 |
T3 | multi | — | 客户端 1: 开启事务 |
T4 | set key2 value2 | — | 客户端1 : 事务命令入列 |
T5 | — | set key1 val1 | 客户端 2:修改 key1的值 |
T6 | exec | — | 客户端 1:执行事务,但是事务会先检查在 T2 时刻被监控的 key1 是否被其他命令修改过。因为客户揣 2 修改过,所以它会回滚事务,事实上如果客户端执行的是 set key1 value1 命令,它也会认为 key1 被修改过,然后返回( nil) ,所以是不会产生 ABA 问题的 |
客户端一
127.0.0.1:6379> FLUSHDB OK 127.0.0.1:6379> 127.0.0.1:6379> SET key1 value1 OK 127.0.0.1:6379> WATCH key1 OK 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> set key2 value2 QUEUED # 在这一步暂停下,打开第二个客户端去修改key1的值,然后再exec 127.0.0.1:6379> exec (nil) 127.0.0.1:6379>[/code]
客户端二:
然后回到客户端1 执行exec
注意 T2 和 T6 时刻命令的说明,数据已经被回滚了,并没有执行事务。
阅读更多- Redis大总结之二:Redis 事务,WATCH命令,生存时间
- redis事务中的WATCH命令和基于CAS的乐观锁
- Redis基础学习--Redis 事务(watch命令)、生存时间、排序、消息通知("发布/订阅"模式)、管道、节省空间
- redis命令详解与使用场景举例——Transaction(事务)
- redis事务中的WATCH命令和基于CAS的乐观锁
- RedisTemplate 事务处理方法 watch multi exec 的使用
- redis事务中的WATCH命令和基于CAS的乐观锁
- redis事务中的WATCH命令和基于CAS的乐观锁
- redis事务中的WATCH命令和基于CAS的乐观锁
- Redis的事务之watch使用
- Redis 的简单操作命令和事务简单使用
- redis实现分布式锁——核心 setx+pipe watch监控key变化-事务
- Redis 常用命令以及使用事务、设置key超时
- watch命令使用介绍
- Linux下利用nc命令来监控检测服务器的端口使用情况
- 16 个 Linux 服务器监控命令和watch
- 16 个 Linux 服务器监控命令和watch
- Linux使用nc命令监控检测服务器端口
- redis安装及使用+常用命令
- 性能优化与故障排除百日谈(3)-监控-使用DBCC命令监控日志空间的使用情况