Redis的事务基于四个命令：

• MULTI
• EXEC
• DISCARD
• WATCH

创建事务

Redis的事务从一个MULTI命令开始，MULTI总会命令返回"ok"。
接着就可以开始输入操作数据，每一条操作命令都会进入队列。
最后执行EXEC，在队列中的命令得到执行。

比如这样：

> MULTIOK> INCR fooQUEUED> INCR barQUEUED> EXEC1) (integer) 12) (integer) 1

如果事务中出现错误怎么办?
首先我们将事务中的错误分为两类：

• 进入队列前发现错误，比如命令的语法错误。
• EXEC执行后发现错误，比如对同一个key执行的两次不同数据类型的操作。

第一种很好理解，就像上面给出的例子中，成功进入队列后会立马返回"QUEUED"。
如果没能进入队列，则整个事务都会失效，提示"Transaction discarded because of previous errors."

关于EXEC执行后出现的错误，凡是成功进入队列的都会被执行，即便同一事物中有执行失败的命令，其余的命令都会得到执行。

这让那些用过关系型数据库的人们感到诧异， 为什么Redis不支持roll back?
对此官网的两点说法：

• Redis commands can fail only if called with a wrong syntax (and the problem is not detectable during the command queueing), or against keys holding the wrong data type: this means that in practical terms a failing command is the result of a programming errors, and a kind of error that is very likely to be detected during development, and not in production.

• Redis is internally simplified and faster because it does not need the ability to roll back.

有人说不支持roll back会引发各种bug。但需要明白的是，roll back不是用来解决编程层面上的错误的。
而且，导致命令失败只有两种可能：

• 语法错误
• 执行了与key的数据类型不匹配的操作

鉴于此，roll back几乎没有任何意义，Redis更倾向于不支持roll back而是保持简洁和高效。

丢弃事务

DISCARD可以用作丢弃当前事务，并将连接状态恢复为正常状态。
使用方法如下：

> SET foo 1OK> MULTIOK> INCR fooQUEUED> DISCARDOK> GET foo"1"

原子性

check-and-set(CAS)之类的操作往往会出现竟态条件。
Redis提供了WATCH用于观察key的变化。
当一个被观察的key在EXEC执行前变化时，整个事务会终止并返回Nil，对该key的观察也会结束。
刚接触WATCH的时候，感觉这种处理方式很晦涩。不能加个显示锁什么的吗？
好在官网给出了充分的说明，先假设Redis没有提供INCR，我们现在要模拟一个递增操作：

val = GET mykeyval = val + 1SET mykey $val

一个client进行该操作时是没有问题，但多个client一起进行该操作时会出现竟态条件。
比如A和B两个client同时进行了GET mykey，得到的都是10，因此两次执行的结果是11而不是12。
而加入WATCH后：

WATCH mykeyval = GET mykeyval = val + 1MULTISET mykey $valEXEC

如果WATCH和EXEC之间有其他的什么东东改变了被观察的key，该事务则会失败。
如果希望本次事务执行成功则需要在循环中执行，当然，这也是一种locking方式。
事实上，多个client访问同一key的冲突并不常见，看具体情况进行操作吧。

相应地，也有UNWATCH可以用于释放所有被观察的key。

比如下面的例子中，事务内的INCR会成功执行：

WATCH keyUNWATCH keyMULTIINCR keyEXEC

Redis - 事务操作