干货:[公粽号:堆栈future]
Redis事务
Redis原子性保证
当Redis采用RDB机制保证数据可靠性时,Redis会按照一定的周期执行内存快照。
一个事务在执行过程中,事务操作对数据所做的修改并不会实时地记录到RDB中,而且,Redis也不会创建RDB快照。我们可以根据故障发生的时机以及RDB是否生成,分成三种情况来讨论事务的原子性保证。
假设事务在执行到一半时,实例发生了故障,在这种情况下,上一次RDB快照中不会包含事务所做的修改,而下一次RDB快照还没有执行。所以,实例恢复后,事务修改的数据会丢失,事务的原子性能得到保证。
假设事务执行完成后,RDB快照已经生成了,如果实例发生了故障,事务修改的数据可以从RDB中恢复,事务的原子性也就得到了保证。
假设事务执行已经完成,但是RDB快照还没有生成,如果实例发生了故障,那么,事务修改的数据就会全部丢失,也就谈不上原子性了。
Redis的事务到底是什么?Redis提供了MULTI、EXEC两个命令
来完成这三个步骤。下面我们来分析下。
第一步,客户端要使用一个命令显式地表示一个事务的开启。在Redis中,这个命令就是MULTI。
第二步,客户端把事务中本身要执行的具体操作(例如增删改数据)发送给服务器端。这些操作就是Redis本身提供的数据读写命令,例如GET、SET等。不过,这些命令虽然被客户端发送到了服务器端,但Redis实例只是把这些命令暂存到一个命令队列中,并不会立即执行。
第三步,客户端向服务器端发送提交事务的命令,让数据库实际执行第二步中发送的具体操作。Redis 提供的EXEC命令就是执行事务提交的。当服务器端收到EXEC命令后,才会实际执行命令队列中的所有命令。
了解了Redis的事务之后我们看下它如何满足ACID
特性之一:原子性的(A)。
#开启事务 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.
#开启事务 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-check-aof
工具检查AOF日志文件,这个工具可以把未完成的事务操作从AOF文件中去除。这样一来,我们使用AOF恢复实例后,事务操作不会再被执行,从而保证了原子性。当然,如果AOF日志并没有开启,那么实例重启后,数据也都没法恢复了,此时,也就谈不上原子性了。总结下Redis原子性保证情况如下:
命令入队时就报错,会放弃事务执行,保证原子性
;
命令入队时没报错,实际执行时报错,不保证原子性
;
EXEC命令执行时实例故障,如果开启了AOF日志,可以保证原子性
。
堆栈future
使很多处于迷茫阶段的coder能从这里找到光明,堆栈创世,功在当代,利在千秋
122篇原创内容