事务机制:Redis能实现ACID属性吗

1,170 阅读7分钟

事务的ACID属性:

  1. 原子性 Automatic:指事务是一个不可分割的工作单位,事务中的操作要么都发生,要么都不发生。
  2. 一致性 Consistency:事务前后数据的完整性必须保持一致,即事务完成后,符合逻辑运算。
  3. 隔离性 Isolation:多个事务的操作互相独立互相封闭,即事务A读取不了事务B的数据,反之亦然。
  4. 持久性 Durability:事务提交,其对系统的影响是永久的。

Redis如何实现事务:

一般来说,事务的操作包括三个步骤。1.开启事务;2.执行事务动作;3.提交事务。这正如我们日常在MySQL中使用的事务一样:

BEGIN;
UPDATE purchase_order SET type = 1 WHERE id = 1;
COMMIT;

在redis中,只不过开启事务的命令是MULTI,提交事务的是EXEC。整个过程大致如下:

  1. 使用MULTI命令显式开启一个事务。
  2. 客户端将事务中所需要执行的命令发送给服务端,服务端将收到的命令暂存到队列中依次执行。
  3. 使用EXEC命令提交事务,当服务器端收到 EXEC 命令后,才会实际执行命令队列中的所有命令。
127.0.0.1:6379> mget a:quantity b:quantity
1) "1"
2) "5"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr a:quantity
QUEUED
127.0.0.1:6379> decr b:quantity
QUEUED
127.0.0.1:6379> exec
1) (integer) 2
2) (integer) 4
127.0.0.1:6379> mget a:quantity b:quantity
1) "2"
2) "4"

在上面我们可以看到,通过使用 MULTI 和 EXEC 命令,我们可以实现多个操作的共同执行,但是这符合事务要求的 ACID 属性吗?

Redis的事务机制能保证哪些属性?

1. 原子性

如果事务正常执行,没有发生任何错误,那么,MULTI 和 EXEC 配合使用,就可以保证多个操作都完成。但是,如果事务执行发生错误了,原子性还能保证吗?我们需要分以下三种情况 —— 命令入队时就报错;命令入队时没报错,实际执行时报错;EXEC 命令执行时实例故障。

第一种情况: 在执行 EXEC 命令前,客户端发送的操作命令本身就有错误(比如语法错误,使用了不存在的命令),在命令入队时就被 Redis 实例判断出来了。

127.0.0.1:6379> mget a:quantity b:quantity
1) "2"
2) "4"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> put a:quantity
(error) ERR unknown command 'put'
127.0.0.1:6379> decr b:quantity
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> mget a:quantity b:quantity
1) "2"
2) "4"

在上面示例中,由于事务里包含了一个 Redis 本身就不支持的 PUT 命令,在 PUT 命令入队时,Redis 就报错了。虽然,事务里还有一个正确的 DECR 命令,但是,在最后执行 EXEC 命令后,整个事务被放弃执行了,所以这种情况是满足原子性的。

第二种情况: 事务操作入队时,命令和操作的数据类型不匹配,但 Redis 实例没有检查出错误。但是,在执行完 EXEC 命令以后,Redis 实际执行这些事务操作时,就会报错。不过,需要注意的是,虽然 Redis 会对错误命令报错,但还是会把正确的命令执行完。在这种情况下,事务的原子性就无法得到保证了。

127.0.0.1:6379> mget a:quantity b:quantity
1) "2"
2) "4"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> lpush a:quantity 2
QUEUED
127.0.0.1:6379> decr b:quantity
QUEUED
127.0.0.1:6379> exec
1) (error) WRONGTYPE Operation against a key holding the wrong kind of value
2) (integer) 3
127.0.0.1:6379> mget a:quantity b:quantity
1) "2"
2) "3"

对于上面的示例,我们很容易联想到数据库中的事务回滚机制,当事务执行失败时,事务中的所有操作都会被撤销,而在redis中并没有提供事务回滚机制。( DISCARD 命令只能用来主动放弃事务执行,把暂存的命令队列清空,起不到回滚的效果)

第三种情况: 在执行事务的 EXEC 命令时,Redis 实例发生了故障,导致事务执行失败。在这种情况下,如果 Redis 开启了 AOF 日志,那么,只会有部分的事务操作被记录到 AOF 日志中。我们需要使用 redis-check-aof 工具检查 AOF 日志文件,这个工具可以把未完成的事务操作从 AOF 文件中去除。这样一来,我们使用 AOF 恢复实例后,事务操作不会再被执行,从而保证了原子性。当然,如果 AOF 日志并没有开启,那么实例重启后,数据也都没法恢复了,此时,也就谈不上原子性了。

2. 一致性

对于一致性,我们还是分为以下三种情况进行分析 —— 命令入队时就报错;命令入队时没报错,实际执行时报错;EXEC 命令执行时实例故障。

第一种情况: 命令入队时就报错。在讨论原子性的时候说过,这种情况下一整个事务都将放弃执行,也就意味着事务执行前后数据的一致,所以这种情况时可以保证一致性的。

第二种情况: 命令入队时没报错,实际执行时报错。这种情况下,事务中部分命令成功部分失败,也不会改变数据库的一致性。

第三种情况: EXEC 命令执行时实例发生故障。这种情况下,数据的一致性就取决于了数据恢复方式了,也就是取决于 AOF 还是 RDB。如果我们压根没有开启 AOF 或 RDB,那么实例故障重启后,数据都没有了,数据库是一致的。如果我们使用了 RDB 快照,因为 RDB 快照不会在事务执行时执行,所以,事务命令操作的结果不会被保存到 RDB 快照中,使用 RDB 快照进行恢复时,数据库里的数据也是一致的。如果我们使用了 AOF 日志,而事务操作还没有被记录到 AOF 日志时,实例就发生了故障,那么,使用 AOF 日志恢复的数据库数据是一致的。如果只有部分操作被记录到了 AOF 日志,我们可以使用 redis-check-aof 清除事务中已经完成的操作,数据库恢复后也是一致的。

3. 隔离性

事务隔离性的保证受到事务并发操作顺序的影响,事务执行有命令入队(EXEC 命令执行前)和命令实际执行(EXEC 命令执行后)两个阶段,所以,我们就针对这两个阶段,分成两种情况来分析:1、并发操作在 EXEC 命令之后被服务器端接收并执行,此时,隔离性可以保证。2、并发操作在命令执行前发生,此时隔离性需要 WATCH 机制来保证,否则隔离性无法保证,WATCH 机制的作用是,在事务执行前,监控一个或多个键的值变化情况,当事务调用 EXEC 命令执行时,WATCH 机制会先检查监控的键是否被其它客户端修改了。如果修改了,就放弃事务执行,避免事务的隔离性被破坏。然后,客户端可以再次执行事务,此时,如果没有并发修改事务数据的操作了,事务就能正常执行,隔离性也得到了保证。。Redis 的 WATCH 机制

4. 持久性

因为 Redis 是内存数据库,所以,数据是否持久化保存完全取决于 Redis 的持久化配置模式。如果 Redis 没有使用 RDB 或 AOF,那么事务的持久化属性肯定得不到保证。如果 Redis 使用了 RDB 模式,那么,在一个事务执行后,而下一次的 RDB 快照还未执行前,如果发生了实例宕机,这种情况下,事务修改的数据也是不能保证持久化的。如果 Redis 采用了 AOF 模式,因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况,所以,事务的持久性属性也还是得不到保证。所以,不管 Redis 采用什么持久化模式,事务的持久性属性是得不到保证的。