写在前面的话
之前在某个网站上看到一个问题：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>
