Redis 事务（Transaction）
Redis通过 MULTI、EXEC、DISCARD、WATCH 等命令来实现事务（transaction）功能。
All the commands in a transaction are serialized and executed sequentially. It can never happen that a request issued by another client is served in the middle of the execution of a Redis transaction. This guarantees that the commands are executed as a single isolated operation.
事务提供了一种将多个命令请求打包，然后一次性、按顺序串行地（executed sequentially）执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。
Either all of the commands or none are processed, so a Redis transaction is also atomic. The EXEC command triggers the execution of all the commands in the transaction, so if a client loses the connection to the server in the context of a transaction before calling the EXEC command none of the operations are performed, instead if the EXEC command is called, all the operations are performed.
以下是一个事务执行的过程，该事务首先以一个MULTI命令为开始，接着将多个命令放入事务当中，最后由 EXEC命令触发这个事务的执行，通过将这个事务提交（commit）给服务器。
Usage
A Redis transaction is entered using the MULTI command. The command always replies with OK. At this point the user can issue multiple commands. Instead of executing these commands, Redis will queue them. All the commands are executed once EXEC is called.
Calling DISCARD instead will flush the transaction queue and will exit the transaction.
> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
> EXEC
1) (integer) 1
2) (integer) 1
As it is possible to see from the session above, EXEC returns an array of replies, where every element is the reply of a single command in the transaction, in the same order the commands were issued.
When a Redis connection is in the context of a MULTI request, all commands will reply with the string QUEUED (sent as a Status Reply from the point of view of the Redis protocol). A queued command is simply scheduled for execution when EXEC is called.
从TCP 通信角度来分析：
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set aaabbbccc 123456
QUEUED
127.0.0.1:6379> set cccbbbaaa 987654
QUEUED
127.0.0.1:6379> get aaabbbccc
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) "123456"
我们总共执行了5条命令，每条命令都会有对应的TCP通讯（每次通讯都会附上这条命令对应的执行内容）：
这点其实是相比较 pipeline而言的，在 pipeline中，所有command都会缓存在 client，只有当执行 EXEC 命令时，才会进行TCP 通讯。
这也意味着，如果执行大量的 transaction，redis server的memory usage会上升（因为有大量未被执行的command 被缓存在 redis server的memory中）；而如果执行大量的 pipeline（而每个pipeline中执行命令数量不多或者这些命令对应执行后的结果的数据量并不大），这时候并不会消耗很多的redis server memory。
Errors inside a transaction
During a transaction it is possible to encounter two kind of command errors:
- A command may fail to be queued, so there may be an error before EXEC is called. For instance the command may be syntactically wrong (wrong number of arguments, wrong command name, …), or there may be some critical condition like an out of memory condition (if the server is configured to have a memory limit using the
maxmemorydirective). - A command may fail after EXEC is called, for instance since we performed an operation against a key with the wrong value (like calling a list operation against a string value).
Clients used to sense the first kind of errors, happening before the EXEC call, by checking the return value of the queued command: if the command replies with QUEUED it was queued correctly, otherwise Redis returns an error. If there is an error while queueing a command, most clients will abort the transaction discarding it.
However starting with Redis 2.6.5, the server will remember that there was an error during the accumulation of commands, and will refuse to execute the transaction returning also an error during EXEC, and discarding the transaction automatically.
Before Redis 2.6.5 the behavior was to execute the transaction with just the subset of commands queued successfully in case the client called EXEC regardless of previous errors. The new behavior makes it much more simple to mix transactions with pipelining, so that the whole transaction can be sent at once, reading all the replies later at once.
Errors happening after EXEC instead are not handled in a special way: all the other commands will be executed even if some command fails during the transaction.
Discarding the command queue
DISCARD can be used in order to abort a transaction. In this case, no commands are executed and the state of the connection is restored to normal.
> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"
Why Redis does not support roll backs?
If you have a relational databases background, the fact that Redis commands can fail during a transaction, but still Redis will execute the rest of the transaction instead of rolling back, may look odd to you.
However there are good opinions for this behavior:
- 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.
An argument against Redis point of view is that bugs happen, however it should be noted that in general the roll back does not save you from programming errors. For instance if a query increments a key by 2 instead of 1, or increments the wrong key, there is no way for a rollback mechanism to help. Given that no one can save the programmer from his or her errors, and that the kind of errors required for a Redis command to fail are unlikely to enter in production, we selected the simpler and faster approach of not supporting roll backs on errors.