事务是指对数据进行读写的一系列操作。事务在执行时,会提供 ACID 属性保证,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)。
事务的执行过程包含三个步骤,Redis 提供了 MULTI、EXEC 两个命令来完成这三个步骤。
#开启事务 127.0.0.1:6379> MULTI OK #将a:stock减1, 127.0.0.1:6379> DECR a:stock QUEUED #将b:stock减1 127.0.0.1:6379> DECR b:stock QUEUED #实际执行事务 127.0.0.1:6379> EXEC 1) (integer) 4 2) (integer) 9
原子性
第一种情况:在执行 EXEC 命令前,客户端发送的操作命令本身就有错误(比如语法错误,使用了不存在的命令),在命令入队时就被 Redis 实例判断出来。
对于这种情况,在命令入队时,Redis 就会报错并且记录下这个错误。此时,还能继续提交命令操作。等到执行 EXEC 命令之后,Redis 就会拒绝执行所有提交的命令操作,返回事务失败的结果,保证了原子性。
#开启事务 127.0.0.1:6379> MULTI OK #发送事务中的第一个操作,但是Redis不支持该命令,返回报错信息 127.0.0.1:6379> PUT a:stock 5 (error) ERR unknown command `PUT`, with args beginning with: `a:stock`, `5`, #发送事务中的第二个操作,这个操作是正确的命令,Redis把该命令入队 127.0.0.1:6379> DECR b:stock QUEUED #实际执行事务,但是之前命令有错误,所以Redis拒绝执行 127.0.0.1:6379> EXEC (error) EXECABORT Transaction discarded because of previous errors.
第二种情况:事务操作入队时,命令和操作的数据类型不匹配,但 Redis 实例没有检查出错误。
在执行完 EXEC 命令以后,Redis 实际执行这些事务操作时,就会报错。不过,虽然 Redis 会对错误命令报错,但还是会把正确的命令执行完。在这种情况下,事务的原子性无法得到保证。
#开启事务 127.0.0.1:6379> MULTI OK #发送事务中的第一个操作,LPOP命令操作的数据类型不匹配,此时并不报错 127.0.0.1:6379> LPOP a:stock QUEUED #发送事务中的第二个操作 127.0.0.1:6379> DECR b:stock QUEUED #实际执行事务,事务第一个操作执行报错 127.0.0.1:6379> EXEC 1) (error) WRONGTYPE Operation against a key holding the wrong kind of value 2) (integer) 8
Redis 中并没有提供回滚机制。 虽然 Redis 提供了 DISCARD 命令,但是,这个命令只能用来主动放弃事务执行,把暂存的命令队列清空,起不到回滚的效果。
#读取a:stock的值4 127.0.0.1:6379> GET a:stock "4" #开启事务 127.0.0.1:6379> MULTI OK #发送事务的第一个操作,对a:stock减1 127.0.0.1:6379> DECR a:stock QUEUED #执行DISCARD命令,主动放弃事务 127.0.0.1:6379> DISCARD OK #再次读取a:stock的值,值没有被修改 127.0.0.1:6379> GET a:stock "4"
第三种情况:在执行事务的 EXEC 命令时,Redis 实例发生了故障,导致事务执行失败。
在这种情况下,如果 Redis 开启了 AOF 日志,那么,只会有部分的事务操作被记录到 AOF 日志中。使用 redis-check-aof 工具检查 AOF 日志文件,这个工具可以把未完成的事务中的操作从 AOF 文件中去除。因此,在使用 AOF 恢复实例后,事务操作不会再被执行,从而保证了原子性。
127.0.0.1:6379> ./redis-check-aof appendonly.aof
如果 AOF 日志并没有开启,那么实例重启后,数据也都没法恢复,也就谈不上原子性了。
一致性
情况一:命令入队时就报错
在这种情况下,事务本身就会被放弃执行,所以可以保证数据库的一致性。
情况二:命令入队时没报错,实际执行时报错
在这种情况下,有错误的命令不会被执行,正确的命令可以正常执行,也不会改变数据库的一致性。
一致性是指系统从一个正确的状态,迁移到另一个正确的状态。而所谓正确的状态就是指当前的状态满足预定的约束就叫做正确的状态。只要没违反规则,就是保证了一致性。 对于 Redis来说,只要这些磁盘文件和内存中的结果保持一致就具有一致性。
情况三:EXEC 命令执行时实例发生故障
总结来说,在命令执行错误或 Redis 发生故障的情况下,Redis 事务机制对一致性属性是有保证的。
隔离性
事务执行又可以分成命令入队(EXEC 命令执行前)和命令实际执行(EXEC 命令执行后)两个阶段:
第一种情况:一个事务的 EXEC 命令还没有执行时,事务的命令操作暂存在命令队列中。
WATCH 机制的作用是,在事务执行前,监控一个或多个键的值变化情况,当事务调用 EXEC 命令执行时,WATCH 机制会先检查监控的键是否被其它客户端修改了。如果修改了,就放弃事务执行,避免事务的隔离性被破坏。然后,客户端可以再次执行事务,此时,如果没有并发修改事务数据的操作了,事务就能正常执行,隔离性也得到了保证。
第二种情况:并发操作在 EXEC 命令之后被服务器端接收并执行。
因为 Redis 是用单线程执行命令,而且,EXEC 命令执行后,Redis 会保证先把命令队列中的所有命令执行完。 所以,在这种情况下,并发操作不会破坏事务的隔离性,如下图所示:
持久性
因为 Redis 是内存数据库,所以,数据是否持久化保存完全取决于 Redis 的持久化配置模式。
所以,不管 Redis 采用什么持久化模式,事务的持久性属性是得不到保证的。