redis 浅谈事务

写在前面的话

之前在某个网站上看到一个问题：redis在什么情况下出现事务不会滚的情况，以此为由并结合 redis 官方文档整理这边笔记。不足之处，请指出，谢谢。

事务

redis支持事务，提供两条重要的保证：

• 在同一个事务的命令都是序列化的和有序执行的。这保证这些命令执行像单个隔离操作。
• 要么所有的命令都执行，要么都不执行。所以事务也是原子性的。exec命令执行事务中的所有命令，如果在调用exce命令前，客户端和服务端断开连接，那么没有一个命令执行，如果exce命令调用，所有的命令执行。当使用aof时，redis确保使用一个系统调用write(2)将事务写到磁盘。然而如果redis服务崩溃或者系统管理员强制杀死，就会有可能只有一部分操作被注册。redis在重启时会发现这种情况，并且错误退出。使用redis-check-aof工具修复aof文件，移除部分事务，因为服务可以重启。

事务内部错误

在事务期间可能会出现两种命令错误：

• 命令可能失败排队，因此在exec调用之前，就会出现错误。如命令的语法错误(参数个数错误，命令名错误)，或者其他灾难环境如oom。
• 命令失败可能在exec调用之后，例如操作一个key使用错误的值（如调用list操作却调用string的命令）。

客户端知道第一种错误，在执行exec之前，通过检测返回值：如果是queued 表明正确的排队，否则返回失败信息。如果在期间出现异常，大多数客户端取消执行事务。

为什么redis不支持回滚

如果你了解数据库，就应该知道事务回滚，事实上redis命令在事务期间失败，仍然执行剩余的操作，而不是回滚，对于你来说，可能太古怪。

• redis命令只有调用错误语法才可能失败（在命令队列队列中可能发现不了），或者操作key使用错误的数据类型：这意味着实际这种命令会导致程序错误，并且这种错误应该在开发环境发现，而不是生产。
• redis内部实现简单和快速的，因为它不需要支持事务回滚。

事务操作命令

multi //开启事务
exec // 执行事务
discard //取消事务块执行
watch
unwatch

事务执行事务回滚失败

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 value1
QUEUED //语法校验通过。
127.0.0.1:6379> set key2 value2
QUEUED
127.0.0.1:6379> incr key1
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
127.0.0.1:6379> get key1
"value1"
127.0.0.1:6379> get key2
"value2"

事务执行完成，但是没有因为错误而失败，这种失败是Key对应的数据类型错误，属于开发阶段的错误，redis检测不出来这种错误，只有实际执行才能校测出问题。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 value1
QUEUED
127.0.0.1:6379> set key2 value2
QUEUED
127.0.0.1:6379> incre key1
(error) ERR unknown command `incre`, with args beginning with: `key1`, 
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get key1
(nil)

这种错误属于语法错误,没有incre命令，redis能检测出这种错误，所以事务执行失败。

取消事务

127.0.0.1:6379> multi 
OK
127.0.0.1:6379> set key1 value1
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get key1
(nil)
127.0.0.1:6379>