Redis事务

什么是Redis事务

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

也就说说 redis 事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。　

Redis事务特性

单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis 事务没有隔离级别的概念：批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。

Redis不保证原子性：Redis 中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

Redis事务命令

命令

说明

MULTI 命令用于开启一个事务，它总是返回 OK 。

MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC 命令被调用时， 所有队列中的命令才会被执行。

另一方面， 通过调用 DISCARD ， 客户端可以清空事务队列， 并放弃执行事务。

事务执行

三个阶段

Redis 事务可以大体分为三个阶段：

1. 开启事务（multi）
2. 命令入队（业务操作）
3. 执行事务（exec）或取消事务（discard）

案例

> multi
OK
> incr star
QUEUED
> incr star
QUEUED
> exec
(integer) 1
(integer) 2

上面的指令演示了一个完整的事务过程，所有的指令在 exec 之前不执行，而是缓存在服务器的一个事务队列中，服务器一旦收到 exec 指令，才开执行整个事务队列，执行完毕后一次性返回所有指令的运行结果。

Redis 事务可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞。

可以保证一个队列中，一次性、顺序性、排他性的执行一系列命令（Redis 事务的主要作用其实就是串联多个命令防止别的命令插队）。也就是说事务可以一次执行多个命令， 并且带有以下两个重要的保证：

• 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

案例

正常执行

可以批处理，挺爽，每条操作成功的话都会各取所需，互不影响，具体过程如下：

我们看到，我们正常的使用 MULTI 开启事务，使用 EXEC 执行事务。

放弃事务

discard 操作表示放弃事务，之前的操作都不算数，具体过程如下：

我们可以看到， 我们使用了 DISCARD 放弃了事务的执行之后，再次使用 GET 获取设置的值，并未获取到，因为事务被放弃执行了。

事务中的错误

上边规规矩矩的操作，看着还挺好，可是事务是为解决数据安全操作提出的，我们用 Redis 事务的时候，可能会遇上以下两种错误：

• 事务在执行 EXEC 之前，入队的命令可能会出错。比如说，命令可能会产生语法错误（参数数量错误，参数名错误等等），或者其他更严重的错误，比如内存不足（如果服务器使用 maxmemory 设置了最大内存限制的话）。
• 命令可能在 EXEC 调用之后失败。举个例子，事务中的命令可能处理了错误类型的键，比如将列表命令用在了字符串键上面，诸如此类。

Redis 针对如上两种错误采用了不同的处理策略，对于发生在 EXEC 执行之前的错误，服务器会对命令入队失败的情况进行记录，并在客户端调用 EXEC 命令时，拒绝执行并自动放弃这个事务（Redis 2.6.5 之前的做法是检查命令入队所得的返回值：如果命令入队时返回 QUEUED ，那么入队成功；否则，就是入队失败）。

对于那些在 EXEC 命令执行之后所产生的错误， 并没有对它们进行特别处理： 即使事务中有某个/某些命令在执行时产生了错误， 事务中的其他命令仍然会继续执行。

全体连坐

某一条操作记录报错的话，exec 后所有操作都不会成功，具体过程如下：

我们可以看到，我们写错了一个命令，属于语法错误，结果我们使用 EXEC 命令执行事务，事务执行失败，并且所有的键都未设置成功。

冤头债主

只有在执行的时候才可以判断出语句错误，其他正确的会被正常执行，具体过程如下：

我们看到，除了 DECR 命令执行失败了，其他命令都执行成功了，因为 DECR 命令需要在执行时才会被发现错误。

Redis事务回滚

如果你有使用关系式数据库的经验，那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令” 这种做法可能会让你觉得有点奇怪。以下是官方的自夸：

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

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

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

带Watch的事务

WATCH 命令用于在事务开始之前监视任意数量的键：当调用 EXEC 命令执行事务时，如果任意一个被监视的键已经被其他客户端修改了，那么整个事务将被打断，不再执行，直接返回失败。

WATCH 命令可以被调用多次。对键的监视从 WATCH 执行之后开始生效，直到调用 EXEC 为止。用户还可以在单个 WATCH 命令中监视任意多个键，就像这样：

redis> WATCH key1 key2 key3 
OK

当 EXEC 被调用时，不管事务是否成功执行，对所有键的监视都会被取消。另外，当客户端断开连接时，该客户端对键的监视也会被取消。我们看个简单的例子，用 watch 监控我的账号余额：

但这个卡，还绑定了我媳妇的微信，如果在我消费的时候，她也消费了，会怎么样呢？现在，我开始消费了两笔，一笔是 20 元，一笔是 10元，但此时我还没确认支付，也就是事务还没提交，如下：

现在，我媳妇使用了另一个客户端，对我卡内余额进行了消费，也就是使用了另一个 Redis 客户端连接到 Redis 服务器，对 balance 变量进行修改，如下：

现在，我开始消费，也就是提交事务，如下：

我们看到，此时事务返回了 nil，即事务执行失败了，因为，在我们使用 WATCH 监控的时候，某个数据被修改了，因此，事务执行失败。

同时，使用无参数的 UNWATCH 命令可以手动取消对所有键的监视。 对于一些需要改动多个键的事务，有时候程序需要同时对多个键进行加锁，然后检查这些键的当前值是否符合程序的要求。 当值达不到要求时，就可以使用 UNWATCH 命令来取消目前对键的监视，中途放弃这个事务，并等待事务的下次尝试。

注意

Redis 事务在发送每个指令到事务缓存队列时都要经过一次网络读写，当一个事务内部的指令较多时，需要的网络 IO 时间也会线性增长。所以通常 Redis 的客户端在执行事务时都会结合 pipeline 一起使用，这样可以将多次 IO 操作压缩为单次 IO 操作。

原文参考：嗨客网（www.haicoder.net）Redis事务