MySQL 在执行事务时,会提供回滚机制,当事务执行发生错误时,事务中的所有操作都会撤销,已经修改的数据也会被恢复到事务执行前的状态。
Redis 中并没有提供回滚机制,虽然 Redis 提供了 DISCARD 命令,但是这个命令只能用来主动放弃事务执行,把暂存的命令队列清空,起不到回滚的效果。
127.0.0.1:6379> get count
"10"
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> INCR count
QUEUED
127.0.0.1:6379> get count
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> get count
"10"
事务执行过程中,如果命令入队时没报错,而事务提交后,实际执行时报错了,正确的命令依然可以正常执行,所以这可以看出 Redis 并不一定保证原子性(原子性:事务中的命令要不全部成功,要不全部失败)。
比如下面这个例子:
127.0.0.1:6379> set name aiver
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set name aiverreading
QUEUED
127.0.0.1:6379> EXPIRE name 10s
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (error) ERR value is not an integer or out of range
127.0.0.1:6379> get name
"aiverreading"
127.0.0.1:6379>
标签:事务,127.0,OK,0.1,redis,6379,QUEUED
From: https://www.cnblogs.com/aiverhua/p/16932261.html