Redis（四）【事务】

Naijia_OvO

已于 2022-09-01 14:43:36 修改

阅读量267

点赞数

分类专栏： # Redis 文章标签： redis 数据库 nosql

于 2022-05-17 16:06:49 首次发布

本文链接：https://blog.csdn.net/Wei_Naijia/article/details/124822616

版权

Redis 专栏收录该内容

14 篇文章 4 订阅

订阅专栏

本文介绍了Redis中的事务处理机制，包括其非原子性、命令入队、执行过程以及事务的开启、执行和放弃。同时，详细阐述了Redis的乐观锁实现——监视（Watch）机制，通过示例展示了在并发情况下如何利用Watch确保数据一致性。内容涵盖事务的正常执行、编译型异常和运行时异常的处理，以及在数据变更情况下的重试策略。

摘要由CSDN通过智能技术生成

四、事务

Redis单条命令保持原子性，但是事务不保证原子性！

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

所有的命令都在事务中，并没有直接被执行！只有发起执行命令的时候才会执行！

Redis事务本质：一组命令的集合！一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行

一次性、顺序性、排他性！执行一些列的命令

redis事务：

开启事务（MULTI ）
命令入队
执行事务

正常执行事务

# 开启事务
127.0.0.1:6379> MULTI
OK
# 命令入队
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
# 执行事务
127.0.0.1:6379> EXEC
1) OK
2) OK
3) "v2"
4) OK

放弃事务

# 开启事务
127.0.0.1:6379> MULTI
OK
# 命令入队
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
# 取消s'w
127.0.0.1:6379> DISCARD
OK
# 事务队列中命令都不会被执行
127.0.0.1:6379> get k3
(nil)

编译型异常（代码问题，事务中的所有命令都不会被执行）

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
# 错误的命令
127.0.0.1:6379> getset k3
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> set k5 v5
QUEUED
# 执行事务也是报错的
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
# 所有的命令都不会被执行
127.0.0.1:6379> get k5
(nil)
127.0.0.1:6379> get k2
(nil)

运行时异常（1/0），如果事务队列中存在语法性，那么执行命令的时候，其它命令是可以正常执行的，错误命令抛出异常

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 "v1"
QUEUED
# 执行的时候失败
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> get k3
QUEUED
127.0.0.1:6379> EXEC
1) OK
# 虽然第二条自增命令报错了,但是依旧执行成功了
2) (error) ERR value is not an integer or out of range
3) OK
4) OK
5) "v3"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> get k3
"v3"

监控（Watch）

悲观锁

无论做什么都会枷锁

乐观锁

认为什么时候都不会出现问题，所以不会上锁！更新数据的时候去判断一下，再次期间是否有人修改过这个数据（version）
获取version
更新的时候比较version

Redis监视测试（成功）

127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
# 监视money
127.0.0.1:6379> WATCH money
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY out 20
QUEUED
# 事务正常结束,数据之间没有发生变动,这个时候正常执行成功
127.0.0.1:6379> EXEC
1) (integer) 80
2) (integer) 20

Redis监视测试（失败）

### 线程1	线程2先执行了更新操作,导致线程1修改失败
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECRBY money 10
QUEUED
127.0.0.1:6379> INCRBY out 10
QUEUED
127.0.0.1:6379> EXEC
(nil)
### 线程2 
[root@vinjcent bin]# redis-cli -p 6379
127.0.0.1:6379> get money
"80"
127.0.0.1:6379> set money 1000
OK

解决

# 如果发现事务执行失败，就先解锁
127.0.0.1:6379> unwatch
OK
# 再加锁(相当于mysql中的getVersion)
127.0.0.1:6379> watch money
# 再执行事务
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECRBY money 10
QUEUED
127.0.0.1:6379> INCRBY out 10
QUEUED
127.0.0.1:6379> EXEC
1) (integer) 990
2) (integer) 30