一、事务
Redis的事务是使用MULTI-EXEC的命令组合,使用它可以提供两个重要的保证:
-
事务是一个被隔离的操作,事务中的方法都会被Redis进行序列化并按顺序执行,事务在执行的过程中不会被其他客户端发生的命令所打断。
-
事务是一个原子性的操作,它要么全部执行,要么全部不执行。
在Redis中使用事务会经过三个过程:
- 开启事务
- 命令进入队列
- 执行事务
命令 | 说明 | 备注 |
---|---|---|
multi | 开启事务命令,之后的命令会进入队列,而不会马上被执行 | 在事务生存期间,所有的Redis关于数据结构的命令都会入队 |
watch key1 [key2…] | 监听某些键,当被监听的键在事务执行前被修改,则事务会被回滚 | 使用乐观锁 |
unwatch key1 [key2…] | 取消监听某些键 | - |
exec | 执行事务,如果被监听的键没有被修改,则执行命令,否则回滚命令 | 在执行事务队列存储命令前,Redis会检测被监听的键值对有没有发生变化,如果没有则执行命令,否则回滚事务 |
discard | 回滚事务 | 回滚进入队列的事务命令,之后就不能再用exec命令提交了 |
在spring中要使用同一个连接操作Redis命令的场景,这时可以使用Spring提供的SessionCallback接口。
package com.codeliu.transaction;
import java.util.List;
import org.junit.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.data.redis.core.RedisOperations;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.SessionCallback;
/**
* 测试Redis事务命令
* @author liu
*/
public class TestTransaction {
@SuppressWarnings({ "resource", "rawtypes", "unchecked" })
@Test
public void testTransaction() {
ApplicationContext applicationContext = new ClassPathXmlApplicationContext("spring.xml");
RedisTemplate rt = (RedisTemplate)applicationContext.getBean("redisTemplate");
@SuppressWarnings("unused")
SessionCallback callBack = (SessionCallback)(RedisOperations ops)->{
ops.multi();
ops.boundValueOps("key1").set("value1");
// 由于命令只是入队列而没有执行,所以此处采用get命令,value返回为null
String value = (String)ops.boundValueOps("key1").get();
System.out.println(value);
// list会保存之前入队列的所有命令执行结果
// 执行事务
List<String> list = ops.exec();
for(String l:list) {
System.out.println(l);
}
// 事务结束后,再获取value
value = (String)ops.boundValueOps("key1").get();
return value;
};
// 执行redis命令
String value = (String)rt.execute(callBack);
System.out.println(value);
}
}
(1)Redis事务回滚
先看下图
可以看到,key1的值为字符串,对他进行自增,事务执行时出现错误,但key1的值为value1,key2的值为空,这说明在命令格式正确但执行出错的情况下,其之前之后的命令都会正常执行。
再看下面的图
可以看到我们使用错误的命令格式,Redis能立即检测出来,之前之后的命令都不会执行,说明事务回滚了。
(2)使用watch命令监控事务
Redis参考了多线程中使用的CAS(比较与交换)去执行的。CAS原理会产生ABA问题
上面表格显示的就是ABA问题。
仅仅记录一个旧值去比较是不足够的,还要通过其他方法避免ABA问题。常见的做法是加入一个version字段,每操作一次version就加1,这样通过version就知道该字段有没有被修改过。
Redis在执行事务的过程中,不会阻塞其他连接的并发,而只是通过比较watch监控的键值对去保证数据的一致性,所以多个Redis事务完全可以在非阻塞的多线程环境中并发执行,而且Redis的事务是不会产生ABA问题的。
时刻 | 客户端1 | 客户端2 | 说明 |
---|---|---|---|
T1 | set key 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 key value1命令,它也会被认为修改过,然后返回nil,所以不会出现ABA问题 |