redis 事务

 
为了确保连续多个操作的原子性,一个成熟的数据库通常都会有事务支持,Redis 也不例外。Redis 的事务使用非常简单,不同于关系数据库,我们无须理解那么多复杂的事务模型,就可以直接使用。不过也正是因为这种简单性,它的事务模型很不严格,这要求我们不能像使用关系数据库的事务一样来使用 Redis。

Redis 事务的基本使用

每个事务的操作都有 begin、commit 和 rollback,begin 指示事务的开始,commit 指示事务的提交,rollback 指示事务的回滚。它大致的形式如下。
begin(); try { command1(); command2(); .... commit(); } catch(Exception e) { rollback(); }
Redis 在形式上看起来也差不多,分别是 multi/exec/discard。multi 指示事务的开始,exec 指示事务的执行,discard 指示事务的丢弃。
> multi OK > incr books QUEUED > incr books QUEUED > exec (integer) 1 (integer) 2
上面的指令演示了一个完整的事务过程,所有的指令在 exec 之前不执行,而是缓存在服务器的一个事务队列中,服务器一旦收到 exec 指令,才开执行整个事务队列,执行完毕后一次性返回所有指令的运行结果。因为 Redis 的单线程特性,它不用担心自己在执行队列的时候被其它指令打搅,可以保证他们能得到的「原子性」执行。
notion image
上图显示了以上事务过程完整的交互效果。QUEUED 是一个简单字符串,同 OK 是一个形式,它表示指令已经被服务器缓存到队列里了。

原子性

事务的原子性是指要么事务全部成功,要么全部失败,那么 Redis 事务执行是原子性的么?
下面我们来看一个特别的例子。
> multi OK > set books iamastring QUEUED > incr books QUEUED > set poorman iamdesperate QUEUED > exec 1) OK 2) (error) ERR value is not an integer or out of range 3) OK > get books "iamastring" > get poorman "iamdesperate
上面的例子是事务执行到中间遇到失败了,因为我们不能对一个字符串进行数学运算,事务在遇到指令执行失败后,后面的指令还继续执行,所以 poorman 的值能继续得到设置。
到这里,你应该明白 Redis 的事务根本不能算「原子性」,而仅仅是满足了事务的「隔离性」,隔离性中的串行化——当前执行的事务有着不被其它事务打断的权利。

discard(丢弃)

Redis 为事务提供了一个 discard 指令,用于丢弃事务缓存队列中的所有指令,在 exec 执行之前。
> get books (nil) > multi OK > incr books QUEUED > incr books QUEUED > discard OK > get books (nil)
我们可以看到 discard 之后,队列中的所有指令都没执行,就好像 multi 和 discard 中间的所有指令从未发生过一样。

一致性

事务的一致性保证会受到错误命令、实例故障的影响。所以,我们按照命令出错和实例故障的发生时机,分成三种情况来看。
情况一:命令入队时就报错
在这种情况下,事务本身就会被放弃执行,所以可以保证数据库的一致性。
情况二:命令入队时没报错,实际执行时报错
在这种情况下,有错误的命令不会被执行,正确的命令可以正常执行,也不会改变数据库的一致性。
情况三:EXEC 命令执行时实例发生故障
在这种情况下,实例故障后会进行重启,这就和数据恢复的方式有关了,我们要根据实例是否开启了 RDB 或 AOF 来分情况讨论下。
如果我们没有开启 RDB 或 AOF,那么,实例故障重启后,数据都没有了,数据库是一致的。
如果我们使用了 RDB 快照,因为 RDB 快照不会在事务执行时执行,所以,事务命令操作的结果不会被保存到 RDB 快照中,使用 RDB 快照进行恢复时,数据库里的数据也是一致的。
如果我们使用了 AOF 日志,而事务操作还没有被记录到 AOF 日志时,实例就发生了故障,那么,使用 AOF 日志恢复的数据库数据是一致的。如果只有部分操作被记录到了AOF 日志,我们可以使用 redis-check-aof 清除事务中已经完成的操作,数据库恢复后也 是一致的。所以,总结来说,在命令执行错误或 Redis 发生故障的情况下,Redis 事务机制对一致性属性是有保证的。接下来,我们再继续分析下隔离性。

隔离性

事务的隔离性保证,会受到和事务一起执行的并发操作的影响。而事务执行又可以分成命令入队(EXEC 命令执行前)和命令实际执行(EXEC 命令执行后)两个阶段,所以,我们就针对这两个阶段,分成两种情况来分析:
  1. 并发操作在 EXEC 命令前执行,此时,隔离性的保证要使用 WATCH 机制来实现,否则隔离性无法保证;
  1. 并发操作在 EXEC 命令后执行,此时,隔离性可以保证。
我们先来看第一种情况。一个事务的 EXEC 命令还没有执行时,事务的命令操作是暂存在命令队列中的。此时,如果有其它的并发操作,我们就需要看事务是否使用了 WATCH 机制。
WATCH 机制的作用是,在事务执行前,监控一个或多个键的值变化情况,当事务调用EXEC 命令执行时,WATCH 机制会先检查监控的键是否被其它客户端修改了。如果修改了,就放弃事务执行,避免事务的隔离性被破坏。然后,客户端可以再次执行事务,此时,如果没有并发修改事务数据的操作了,事务就能正常执行,隔离性也得到了保证。
WATCH 机制的具体实现是由 WATCH 命令实现的,我给你举个例子,你可以看下下面的图,进一步理解下 WATCH 命令的使用。
notion image
在 t1 时,客户端 X 向实例发送了 WATCH 命令。实例收到 WATCH 命令后,开始监测a:stock 的值的变化情况。
紧接着,在 t2 时,客户端 X 把 MULTI 命令和 DECR 命令发送给实例,实例把 DECR 命令暂存入命令队列。
在 t3 时,客户端 Y 也给实例发送了一个 DECR 命令,要修改 a:stock 的值,实例收到命令后就直接执行了。
等到 t4 时,实例收到客户端 X 发送的 EXEC 命令,但是,实例的 WATCH 机制发现a:stock 已经被修改了,就会放弃事务执行。这样一来,事务的隔离性就可以得到保证了。
当然,如果没有使用 WATCH 机制,在 EXEC 命令前执行的并发操作是会对数据进行读写的。而且,在执行 EXEC 命令的时候,事务要操作的数据已经改变了,在这种情况下,
Redis 并没有做到让事务对其它操作隔离,隔离性也就没有得到保障。下面这张图显示了没有 WATCH 机制时的情况,你可以看下。
notion image
在 t2 时刻,客户端 X 发送的 EXEC 命令还没有执行,但是客户端 Y 的 DECR 命令就执行了,此时,a:stock 的值会被修改,这就无法保证 X 发起的事务的隔离性了。
刚刚说的是并发操作在 EXEC 命令前执行的情况,下面我再来说一说第二种情况:并发操作在 EXEC 命令之后被服务器端接收并执行。
因为 Redis 是用单线程执行命令,而且,EXEC 命令执行后,Redis 会保证先把命令队列中的所有命令执行完。所以,在这种情况下,并发操作不会破坏事务的隔离性,如下图所示:
notion image
最后,我们来分析一下 Redis 事务的持久性属性保证情况。

持久性

因为 Redis 是内存数据库,所以,数据是否持久化保存完全取决于 Redis 的持久化配置模式。
如果 Redis 没有使用 RDB 或 AOF,那么事务的持久化属性肯定得不到保证。如果 Redis使用了 RDB 模式,那么,在一个事务执行后,而下一次的 RDB 快照还未执行前,如果发生了实例宕机,这种情况下,事务修改的数据也是不能保证持久化的。
如果 Redis 采用了 AOF 模式,因为 AOF 模式的三种配置选项 no、everysec 和 always都会存在数据丢失的情况,所以,事务的持久性属性也还是得不到保证。所以,不管 Redis 采用什么持久化模式,事务的持久性属性是得不到保证的。
notion image

优化

上面的 Redis 事务在发送每个指令到事务缓存队列时都要经过一次网络读写,当一个事务内部的指令较多时,需要的网络 IO 时间也会线性增长。所以通常 Redis 的客户端在执行事务时都会结合 pipeline 一起使用,这样可以将多次 IO 操作压缩为单次 IO 操作。比如我们在使用 Python 的 Redis 客户端时执行事务时是要强制使用 pipeline 的。
pipe = redis.pipeline(transaction=true)pipe.multi()pipe.incr("books")pipe.incr("books")values = pipe.execute()

Watch

考虑到一个业务场景,Redis 存储了我们的账户余额数据,它是一个整数。现在有两个并发的客户端要对账户余额进行修改操作,这个修改不是一个简单的 incrby 指令,而是要对余额乘以一个倍数。Redis 可没有提供 multiplyby 这样的指令。我们需要先取出余额然后在内存里乘以倍数,再将结果写回 Redis。
这就会出现并发问题,因为有多个客户端会并发进行操作。我们可以通过 Redis 的分布式锁来避免冲突,这是一个很好的解决方案。分布式锁是一种悲观锁,那是不是可以使用乐观锁的方式来解决冲突呢?
Redis 提供了这种 watch 的机制,它就是一种乐观锁。有了 watch 我们又多了一种可以用来解决并发修改的方法。 watch 的使用方式如下:
while True: do_watch() commands() multi() send_commands() try: exec() break except WatchError: continue
watch 会在事务开始之前盯住 1 个或多个关键变量,当事务执行时,也就是服务器收到了 exec 指令要顺序执行缓存的事务队列时,Redis 会检查关键变量自 watch 之后,是否被修改了 (包括当前事务所在的客户端)。如果关键变量被人动过了,exec 指令就会返回 null 回复告知客户端事务执行失败,这个时候客户端一般会选择重试。
> watch books OK > incr books # 被修改了 (integer) 1 > multi OK > incr books QUEUED > exec # 事务执行失败 (nil)
当服务器给 exec 指令返回一个 null 回复时,客户端知道了事务执行是失败的,通常客户端 (redis-py) 都会抛出一个 WatchError 这种错误,不过也有些语言 (jedis) 不会抛出异常,而是通过在 exec 方法里返回一个 null,这样客户端需要检查一下返回结果是否为 null 来确定事务是否执行失败。
注意事项
Redis 禁止在 multi 和 exec 之间执行 watch 指令,而必须在 multi 之前做好盯住关键变量,否则会出错。
接下来我们使用 Python 语言来实现对余额的加倍操作。
# -*- coding: utf-8 import redis def key_for(user_id): return "account_{}".format(user_id) def double_account(client, user_id): key = key_for(user_id) while True: client.watch(key) value = int(client.get(key)) value *= 2 # 加倍 pipe = client.pipeline(transaction=True) pipe.multi() pipe.set(key, value) try: pipe.execute() break # 总算成功了 except redis.WatchError: continue # 事务被打断了,重试 return int(client.get(key)) # 重新获取余额 client = redis.StrictRedis() user_id = "abc" client.setnx(key_for(user_id), 5) # setnx 做初始化 print double_account(client, user_id)
下面我们再使用 Java 语言实现一遍。
import java.util.List; import redis.clients.jedis.Jedis; import redis.clients.jedis.Transaction; public class TransactionDemo { public static void main(String[] args) { Jedis jedis = new Jedis(); String userId = "abc"; String key = keyFor(userId); jedis.setnx(key, String.valueOf(5)); # setnx 做初始化 System.out.println(doubleAccount(jedis, userId)); jedis.close(); } public static int doubleAccount(Jedis jedis, String userId) { String key = keyFor(userId); while (true) { jedis.watch(key); int value = Integer.parseInt(jedis.get(key)); value *= 2; // 加倍 Transaction tx = jedis.multi(); tx.set(key, String.valueOf(value)); List<Object> res = tx.exec(); if (res != null) { break; // 成功了 } } return Integer.parseInt(jedis.get(key)); // 重新获取余额 } public static String keyFor(String userId) { return String.format("account_%s", userId); } }
我们常常听说 Python 的代码要比 Java 简短太多,但是从这个例子中我们看到 Java 的代码比 python 的代码也多不了多少,大约只多出 50%。
 
 
在执行事务时,如果 Redis 实例发生故障,而 Redis 使用的 RDB 机制,事务的原子性还能否得到保证?
我觉得是可以保证原子性的。
如果一个事务只执行了一半,然后 Redis 实例故障宕机了,由于 RDB 不会在事务执行时执行,所以 RDB 文件中不会记录只执行了一部分的结果数据。之后用 RDB 恢复实例数据,恢复的还是事务之前的数据。但 RDB 本身是快照持久化,所以会存在数据丢失,丢失的是距离上一次 RDB 之间的所有更改操作。
关于 Redis 事务的使用,有几个细节我觉得有必要补充下,关于 Pipeline 和 WATCH 命令的使用。
1、在使用事务时,建议配合 Pipeline 使用。
a) 如果不使用 Pipeline,客户端是先发一个 MULTI 命令到服务端,客户端收到 OK,然后客户端再发送一个个操作命令,客户端依次收到 QUEUED,最后客户端发送 EXEC 执行整个事务(文章例子就是这样演示的),这样消息每次都是一来一回,效率比较低,而且在这多次操作之间,别的客户端可能就把原本准备修改的值给修改了,所以无法保证隔离性。
b) 而使用 Pipeline 是一次性把所有命令打包好全部发送到服务端,服务端全部处理完成后返回。这么做好的好处,一是减少了来回网络 IO 次数,提高操作性能。二是一次性发送所有命令到服务端,服务端在处理过程中,是不会被别的请求打断的(Redis单线程特性,此时别的请求进不来),这本身就保证了隔离性。我们平时使用的 Redis SDK 在使用开启事务时,一般都会默认开启 Pipeline 的,可以留意观察一下。
2、关于 WATCH 命令的使用场景。
a) 在上面 1-a 场景中,也就是使用了事务命令,但没有配合 Pipeline 使用,如果想要保证隔离性,需要使用 WATCH 命令保证,也就是文章中讲 WATCH 的例子。但如果是 1-b 场景,使用了 Pipeline 一次发送所有命令到服务端,那么就不需要使用 WATCH 了,因为服务端本身就保证了隔离性。
b) 如果事务 + Pipeline 就可以保证隔离性,那 WATCH 还有没有使用的必要?答案是有的。对于一个资源操作为读取、修改、写回这种场景,如果需要保证事物的原子性,此时就需要用到 WATCH 了。例如想要修改某个资源,但需要事先读取它的值,再基于这个值进行计算后写回,如果在这期间担心这个资源被其他客户端修改了,那么可以先 WATCH 这个资源,再读取、修改、写回,如果写回成功,说明其他客户端在这期间没有修改这个资源。如果其他客户端修改了这个资源,那么这个事务操作会返回失败,不会执行,从而保证了原子性。
细节比较多,如果不太好理解,最好亲自动手试一下。