0


Redis(02)——事务管理

事务概念

Redis事务的本质是一组命令的集合。事务支持一次执行多个命令,一个事务中所有命令都会被序列化,在事务执行过程中,会按照顺序串行化执行队列中的命令,其他客户端提交的命令请求不会插入到事务执行命令序列中

  1. Redis事务没有隔离级别

批量操作在发送EXEC命令前被放入队列缓存,并不会被实际执行,也就不存在事务内的查询要看到事务里的更新,事务外查询不能看到

  1. Redis不保证原子性、不支持回滚

Redis中单条命令是原子性执行的,但事务不保证原子性,且没有回滚。事务中任意命令执行失败,其余的命令仍会被执行

事务超时
Redis 事务支持超时。Redis 事务超时是指在指定的时间内没有执行 EXEC 命令,那么该事务就会被自动回滚。
Redis 事务超时可以防止事务长时间处于打开状态,从而导致死锁或其他问题。
Redis 事务超时可以通过以下两种方式设置:

  1. 显式超时:为了避免事务超时,可以在事务中显式地使用 EXPIRE 命令为事务设置显式超时。例如,以下命令将为当前事务设置 10 秒的超时:EXPIRE my_transaction 10
  2. 隐式超时:如果在配置文件中设置了事务超时,那么所有事务都会隐式地具有该超时值。例如,以下配置将为所有事务设置 30 秒的超时:transaction-timeout 30

Redis 事务超时优点

  1. 防止死锁:如果一个事务长时间处于打开状态,那么它可能会导致死锁。例如,如果两个事务同时尝试修改同一个键,那么这两个事务都会被阻塞,并且都不能执行。Redis 事务超时可以防止这种情况的发生,因为如果一个事务在超时时间内没有执行 EXEC 命令,那么它就会被自动回滚。
  2. 提高性能:Redis 事务超时可以提高 Redis 的性能。如果一个事务长时间处于打开状态,那么它会占用 Redis 的资源,并且可能会导致 Redis 的性能下降。Redis 事务超时可以防止这种情况的发生,因为如果一个事务在超时时间内没有执行 EXEC 命令,那么它就会被自动回滚,并且 Redis 的资源就会被释放。

事务操作

  1. watch key1[key2…]:监视一或多个key,如果在事务执行之前,被监视的key被其他命令改动,则事务被打断(类似乐观锁)
  2. multi:标记一个事务块的开始(queued)
  3. exec:执行所有事务块的命令(一旦执行exec后,之前加的监控锁都会被取消掉)
  4. discard:取消事务,放弃事务块中的所有命令
  5. unwatch:取消watch对所有key的监控

基本使用

127.0.0.1:6379> multi   # 开启事务
OK127.0.0.1:6379> set k1 v1
QUEUED127.0.0.1:6379> set k2 v2
QUEUED127.0.0.1:6379> get k2
QUEUED127.0.0.1:6379> set k3 v3
QUEUED127.0.0.1:6379> exec  # 执行事务
1)OK2)OK3)"v2"4)OK
127.0.0.1:6379> multi     # 开启事务
OK127.0.0.1:6379> set k4 v4
QUEUED127.0.0.1:6379> discard     # 放弃事务    
OK127.0.0.1:6379> get k4    # 事务中的命令都不会被执行
(nil)

编译型异常

若在事务队列中存在命令性错误(类似于Java编译性错误),事务中的所有命令都不会被执行

127.0.0.1:6379> multi
OK127.0.0.1:6379> set k1 v1
QUEUED127.0.0.1:6379> getset k1
(error)ERR wrong number of arguments for'getset' command
127.0.0.1:6379> set k2 v2
QUEUED127.0.0.1:6379> get k2
QUEUED127.0.0.1:6379> exec
(error)EXECABORTTransaction discarded because of previous errors.127.0.0.1:6379> get k2
(nil)

运行时异常

如果事务队列中存在语法性(类似于Java的1/0的运行时异常),那么执行命令的时候,其他命令是可以正常执行的,错误命令会抛出异常

127.0.0.1:6379> multi
OK127.0.0.1:6379> set k1 "v1"QUEUED127.0.0.1:6379> incr k1
QUEUED127.0.0.1:6379> set k3 v3
QUEUED127.0.0.1:6379> get k3
QUEUED127.0.0.1:6379> exec
1)OK2)(error)ERR value is not an integer or out of range  # 虽然这条命令报错,但是依旧执行成功
3)OK4)"v3"

watch监控

使用watch检测k1,事务期间k1数据未变动,事务执行成功
image.png
使用watch检测k1,在开启事务后,在新窗口执行新操作,更改k1的值,模拟其他客户端在事务执行期间更改watch监控的数据,执行EXEC命令后,事务未成功执行
image.png
一旦执行EXEC开始事务的执行后,无论事务使用执行成功与否,WATCH对变量的监控都将被取消,当事务执行失败后,需重新执行WATCH命令对变量进行监控,并开启新的事务进行操作
注意:watch指令类似于乐观锁,在事务提交时,如果watch监控的多个KEY中任何KEY的值已经被其他客户端更改,则使用EXEC执行事务时,事务队列将不会被执行,同时返回Nullmulti-bulk应答以通知调用者事务执行失败

事务超时

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> EXPIRE my_transaction 10(integer)1127.0.0.1:6379> SET foo bar
QUEUED
127.0.0.1:6379> SET baz qux
QUEUED
127.0.0.1:6379> EXEC
(integer)1
标签: redis

本文转载自: https://blog.csdn.net/peng_gx/article/details/136065468
版权归原作者 爱编程的小生 所有, 如有侵权,请联系我们删除。

“Redis(02)——事务管理”的评论:

还没有评论