Redis事务
Redis 事务提供了一种将多个命令请求打包的功能。然后,再按顺序执行打包的所有命令,并且不会被中途打断。
但是,事务中的每条命令都会与 Redis 服务器进行网络交互,比较浪费资源
所以,日常开发中不建议使用Redis事务
Redis事务操作
使用redis事务的过程是这样的:
- 开始事务(MULTI);
- 命令入队(批量操作 Redis 的命令,先进先出的顺序执行);
- 执行事务(EXEC)。
你也可以通过DISCARD命令取消一个事务
MULTI命令后可以输入多个命令,Redis 不会立即执行这些命令,而是将它们放到队列,当调用了 EXEC 命令后,再执行所有的命令。
举例
1.首先我们在客户端1开启事务,然后设置key1为111
2.然后在客户端2获取key1,是获取不到的
3.这时候执行事务
4.再去客户端2里查询key1,可以查到
watch操作
你可以通过WATCH命令监听指定的 Key,当调用exec命令执行事务时,如果一个被watch命令监视的 Key 被 其他客户端/Session 修改的话,整个事务都不会被执行。
会发生三种情况:
1.同一个session中,watch监视的key在multi之前被修改,那么这个事务不会被执行
2.同一个session中,watch监视的key在事务内部被修改,那么这个事务还是会执行成功
3.同一个session中,watch监视的key在事务内部被修改,但是在事务提交之前被其他 session 修改,那么事务不会被执行
下面是第三种情况举例
举例
1.首先我们在客户端1设置一个key1为111,然后使用watch监听key1,然后开启事务,操作key1
2.这时候,我们去客户端2修改key1
3.客户端1提交事务,发现提交失败。发现key1是客户端2修改的值,也就是客户端1的事务并没有执行成功
Redis事务特性
我们知道事务具有四大特性:
1. (A)原子性,2.(C) 一致性,3.(I) 隔离性,4.(D) 持久性。
但是,在Redis 中不太一样
Redis事务不具备原子性
原子性是指务是最小的执行单位,不允许分割。事务的原子性确保动作要么全部完成,要么完全不起作用。但是,在redis中,并没有约束和回滚机制,如果事务中的命令出现执行失败的情况,也不会回滚,其他命令依然会执行成功
Redis事务不具备一致性
redis没有约束,也没有回滚机制,事务执行过程中如果某个修改操作出现失败,就可能引起不一致的情况
况且,我们通常说AID保证C,连AID都无法保证,那一致性也更不用说了
Redis事务不涉及隔离性
因为redis是一个单线程模型的服务器程序,所有请求和事务都是串行执行的,自然也就不讨论有没有隔离性了
Redis事务不具备持久性
redis本身就是内存数据库,数据存储在内存中,是不具备持久性的
虽然redis也提供了RDB和AOF这样的持久化机制,但和事务没啥关系
redis事务的错误
1.若在事务队列中存在命令性错误,则执行EXEC命令时,所有命令都不会执行
2.若在事务队列中存在语法性错误,则执行EXEC命令时,其他正确命令会被执行,错误命令抛出异常。
总之,在命令入队时,redis会简单检查语法是否出错,如果出错,视为整个事务无效
但是如果逻辑错了,命令入队的时候是不检查的,只有执行的时候才报错,但其他操作也不会回滚
命令性错误
只有出错的命令不会执行,其他命令依然会执行,这违反了事务的原子性
语法(编译)性错误
在事务中,出现语法错误,会直接报错,后面就算再用exec,之前输入的操作也不会提交执行。
也就是整个事务都不会执行