redis

Redis实例发生故障,而Redis使用RDB机制,事务的原子性

2021-12-26  本文已影响0人  stackfuture
宫粽号:堆栈future

Redis实例发生故障,而Redis使用的RDB机制,事务的原子性还能否得到保证?


干货:[公粽号:堆栈future]

Redis事务讲解

Redis原子性保证


当Redis采用RDB机制保证数据可靠性时,Redis会按照一定的周期执行内存快照。

一个事务在执行过程中,事务操作对数据所做的修改并不会实时地记录到RDB中,而且,Redis也不会创建RDB快照。我们可以根据故障发生的时机以及RDB是否生成,分成三种情况来讨论事务的原子性保证。

  1. 假设事务在执行到一半时,实例发生了故障,在这种情况下,上一次RDB快照中不会包含事务所做的修改,而下一次RDB快照还没有执行。所以,实例恢复后,事务修改的数据会丢失,事务的原子性能得到保证。

  2. 假设事务执行完成后,RDB快照已经生成了,如果实例发生了故障,事务修改的数据可以从RDB中恢复,事务的原子性也就得到了保证。

  3. 假设事务执行已经完成,但是RDB快照还没有生成,如果实例发生了故障,那么,事务修改的数据就会全部丢失,也就谈不上原子性了。

Redis的事务到底是什么? Redis提供了MULTI、EXEC两个命令来完成这三个步骤。下面我们来分析下。

了解了Redis的事务之后我们看下它如何满足ACID特性之一:原子性的(A)。

  1. 第一种情况是,在执行EXEC命令前,客户端发送的操作命令本身就有错误(比如语法错误,使用了不存在的命令),在命令入队时就被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.
  1. 第一种情况是,事务操作入队时,命令和操作的数据类型不匹配,但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
  1. 最后,我们再来看下第三种情况:在执行事务的EXEC命令时,Redis实例发生了故障,导致事务执行失败。 在这种情况下,如果Redis开启了AOF日志,那么,只会有部分的事务操作被记录到AOF日志中。我们需要使用redis-check-aof工具检查AOF日志文件,这个工具可以把未完成的事务操作从AOF文件中去除。这样一来,我们使用AOF恢复实例后,事务操作不会再被执行,从而保证了原子性。当然,如果AOF日志并没有开启,那么实例重启后,数据也都没法恢复了,此时,也就谈不上原子性了。

总结下Redis原子性保证情况如下

上一篇 下一篇

猜你喜欢

热点阅读