Redis事务

相关命令：
DISCARD: 清空事务队列
EXEC：顺序执行事务队列中的所有命令
MULTI：进入事务
WATCH：监控某/某些键
UNWATCH：解决某/某些/所有键的监控

MULTI, EXEC, DISCARD 和 WATCH是Redis事务的基础。它允许我们一步执行一组命令，当然这有两个要求：

1. 事务中的所有命令都被顺序序列化并顺序执行。Redis在执行一个事务的过程中不会处理其他client的请求，这样就保证了将这一组命令作为单个隔离操作。
2. “原子性”（这一组命令要么都执行（但是当某命令错误时，不影响其他命令执行），要么都不执行。）EXEC命令触发执行事务中所有命令。因此，如果在执行EXEC命令前，client与Redis server失去连接，那么这个事务不会执行任何操作。当使用AOF（append-only file）时，Redis使用single write(2) syscall将事务写入磁盘。若当仅写入一部分事务时，Redis server崩溃或被kill了，Redis server会在重启是进行检测，如果是这种情况会退出并显示错误。此时，我们需要使用redis-check-aof工具来修复AOF文件，删除写入的这部分事务，然后重新启动Redis server。由于Redis不能回滚，并不支持严格意义上的原子性。

在Redis 2.2之后，Redis允许以乐观锁的形式进行check-and-set（CAS）操作。

1. 用法

使用MULTI命令进入Redis事务。在事务模式下，用户可以使用多个命令，然而并不会执行这些命令，而是讲这些命令放入队列中。只有当调用EXEC命令时，才会执行所有命令。

使用DISCARD命令会刷新事务队列（也就是清空了）并退出事务模式。

> set foo 2
OK
> set bar 3
OK
> multi # 进入事务
OK
> incr foo
QUEUED
> incr bar
QUEUED
> exec
1) 3
2) 4
# 执行完exec会自动退出事务。

当Redis处于MULTI命令上下文时，所有命令的回复都是QUEUED（入队）。执行完1次EXEC之后会自动退出事务模式。EXEC命令的回复结果是一个数组，会对事务中的每个命令按顺序回复。

2. 事务中的错误

在事务执行过程中可能会遇到两种命令error：

1. 命令加入事务队列（简称，入队）失败。因此，在EXEC调用之前可能会有error。例如，命令的参数数量不对，错误的命令名称，或者内存不足等原因。
2. 调用EXEC命令后失败。例如，对字符串值调用list操作。

client通过检查进行入队的命令的返回值来感知是否出现第一类error，如果命令回复"QUEUED"，则表示入队成功，否则Redis会返回1个error。如果入队出现error，通常是放弃此事务。

从 Redis 2.6.5 开始，Redis server会记住在入队过程中发生的error，并在EXEC期间拒绝执行事务，返回错误并自动丢弃该事务。

在 Redis 2.6.5 之前，只有所有命令都入队成功后，才能调用 EXEC。这样修改使得事务和 pipeling 之间的配合更简单。

调用 EXEC 之后的error处理：在事务中，即使某些命令执行失败，其他命令仍然会被执行。下面的例子证明这个结论。

> multi
OK
> set a abc
QUEUED
> lpop a
QUEUED
> exec
1) OK
2) WRONGTYPE Operation against a key holding the wrong kind of value

3. 为什么Redis不支持回滚？

如果你有关系型数据的经验，那么“Redis在事务中某些命令失败是不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。

以下是这种做法的有点：

• Redis 命令只会因为错误的语法而失败（并且这些问题不能自入队时发现），或者是命令用在了错误类型的键上面：这也就是说，从实用性角度来讲，失败的命令是由编程错误造成的，而这些错误应该在开发过程中被发现，而不应该出现在生产环境中。
• 因为不需要支持回滚，所以Redis 内部更简单、快速。

有种观点认为 Redis 处理事务的做法会产生 bug，然而需要注意的是，通常情况下，回滚并不能解决编程错误带来的问题。例如，你想通过 INCR 命令将键的值加1，却不小心加了2，又或者对错误类型的键执行了 INCR 命令，回滚是无法处理这些情况的。

鉴于没有任何机制能够避免程序员自己造成的错误，并且这类错误通常不会再生产环境中出现，所有 Redis 选择了更简单、更快速的无回滚方式来处理事务。

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

4. 丢弃事务队列

DISCARD 命令被用来中止事务，不会有任何命令被执行并退出事务模式。

> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"

5. 使用 check-and-set 实现乐观锁

WATCH为Redis事务提供check-and-set（CAS）行为。WATCHed的键会被监控，方便Redis知道该键做了哪些改变。当调用EXEC之前，只要有1个WATCHed的命令被修改了，整个事务就会被中止，并且EXEC回复NULL来通知client该事务失败了。

val = GET mykey # 获取mykey的值
val = val + 1 # 对mykey的值加1
SET mykey $val # 将加1后的值赋值给mykey

举个例子，client A和 client B同时对"mykey"的值（原来的值为10）进行加1，这样就会产生竞争，最终的结果可能是11而不是12（因为当client A和client B获取mykey的值的时候得到的都是10）。

在这种情况下使用WATCH可以解决：

WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

使用上面的代码，如果存在竞争，并且另一个客户端在调用WATCH和调用EXEC之间的时间内修改了val的结果，则事务将失败。

6. WATCH的原理是啥？

WATCH 使得 EXEC 命令的执行有了前提条件：只有当我们 WATCHed 的键没有被其他 client 修改时，才让 Redis 去执行事务。

需要注意的是，如果在 WATCH 过程中，该键过期了，那么 EXEC 命令仍然会执行。

WATCH 可以多次调用。WATCH 关注的是从WATCH 开始到 EXEC 之间，所 WATCH 的东西的修改。

当调用 EXEC 时，不管事务是否中止，所有的键都是 UNWATCHed，同理，当 client 连接关闭时，所有东西都将变为UNWATCHed 。

为了清空对所有键的 WATCHed ，可以使用 UNWATCH 命令。当然也可以 UNWATCH 指定的键。

7. 使用 WATCH 实现 ZPOP命令

下面的例子证明如何用 WATCH 命令创建新的原子操作。ZPOP ：从 Sorted set 中原子性地弹出最低分的元素。

WATCH zset
element = ZRANGE zset 0 0
MULTI
ZREM zset element
EXEC

如果 EXEC 失败，只需重复该操作即可。

8. Redis脚本和事务

Redis script 是事务性的，所以 Redis 事务能做的事情， Redis script 也都能做，而且 Redis script 通常更快、更简单。

Redis script 就是用来代替 Redis transaction 的，但短期内没有删除Redis transaction 的打算，所以这两者在功能上重复了。

9. 总结

对于事务的4个特性ACID：
A：Redis事务不满足。因为不支持回滚，操作成功才会写入AOF，而不是执行前就写入AOF，所以无法回滚，当然这使得Redis更简单，高效。
C：由于不支持A，严格来说也就不支持C了。除了业务中需要回滚外，其他一致性都满足。
I：由于Redis是单线程，当 Redis 执行事务时，Redis 的服务端保证在执行事务期间不会对事务进行中断，所以，Redis 事务总是以串行的方式运行，具备隔离性。
D：只要Redis开启了持久化（RDB或AOF），就具有持久性。

参考文献

[1] Redis事务的分析、改进及为啥不支持回滚
[2] Redis官方文档 事务
[3] Redis到底有没有ACID事务