一、Redis事务
Redis的事务是使用 MULTI-EXEC的命令组合,使用它可以提供两个重要的保证 :
-
事务是一个被隔离的操作,事务中的方法都会被 Redis 进行序列化并按顺序执行, 事务在执行的过程中不会被其他客户端发生的命令所打断。
-
事务是一个原子性的操作,它要么全部执行,要么就什么都不执行。
在 Redis 中使用事务会经过 3 个过程:开启事务,命令进入队列,执行事务。
redis事务相关命令:
1.Redis 的基础事务
在 Redis 中 开启事务是 multi 命令,而执行事务是exec命令。 multi 到 exec 命令之间的 Redis 命令将采取进入队列的形式,直至 exec 命令的出现,才会一次性发送队列里的命令去执行 ,而在执行这些命令的时候其他客户端就不能再插入任何命令了,这就是 事务机制。 执行过程如下:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> exec
1) OK
2) "v1"
由上可以看出,先用multi开启事务,然后发现输入set和get后并没有马上执行,而是进入了“QUEUED”,进入了存储队列。接着执行exec命令,发现set和get命令都执行并返回结果了。
如果回滚事务,则可以使用 discard 命令,它就会进入在事务队列中的命令,这样事务中的方法就不会被执行了,使用 discard命令取消事务如下:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> exec
(error) ERR EXEC without MULTI
当我们使用了 discard命令后,再使用 exec命令时就会报错,因为 discard命令已经取消了事务中的命令,而到了 exec命令时,队列里面己经没有命令可以执行了,所以就出现了报错的情况。
在Spring中要使用同一个连接操作Redis命令的场景,这个时候我们借助的是 Spring提供的 SessionCallback接口,采用 Spring去实现本节的命令:
使用了 SessionCallBack 接口,从而保证所有的命令都是通过同一个Redis 的连接进行操作的。在使用 multi命令后, 要特别注意的是,使用 get等返回值的方法一律返回为空,因为在 Redis 中它只是把命令缓存到队列中,而没有去执行 。 使用 exec 后就会执行事务,执行完了事务后,执行 get命令就能正常返回结果了。最后使用 redisTemplate.execute(callBack);就能执行我们在 SessionCallBack 接口定义的Lambda 表达式的业务逻辑,并将获得其返回值。
执行结果:事务执行过程中,命令入队列,而没有被执行,所以 value 为 空 : value=null valuel
如果我们希望得到 Redis 执行事务各个命令的结果,可以用这行代码 :
List list = ops.exec () ; //执行事务
这段代码将返回之前在事务队列中所有命令的执行结果,并保存在一个 List 中,我们只要在 SessionCallback 接口的 execute 方法中将 list返回,就可以在程序中获得各个命令执行的结果了 。
2.探索Redis事务回滚
Redis的事务回滚分为两种情况:一种是命令格式正确而数据类型不符合,一种是命令格式不正确。
如上图,就是数据类型不符合,使用命令 incr对其自增,但是命令只会进入事务队列,而没有被执行,所以它不会有任何的错误发生,而是等待 exec命令的执行。当 exec命令执行后,之前进入队列的命令就依次执行,当遇到 incr时发生命令操作的数据类型错误,所以显示出了错误,而其之前和之后的命令都会被正常执行。注意,这里命令格式是正确的,问题在于数据类型,对于命令格式是错误的却是另外一种情形,如图: