redis的事务可以理解为一系列串行命令的集合。redis的事务和单条命令一样,都是redis的最小执行单位,因此一个事务内的命令,要么全部执行,要么全部不执行。事务的概念对于熟悉数据库的人们并不陌生,而redis作为一个数据库系统,也对事务进行了一定的支持。
redis实现事务的方式简单来说是将一系列的命令先保存在一个队列中,然后交给redis串行化的顺序执行。
2.1 MULTI(开启事务)
MULTI命令:用于开启redis事务。在同一个客户端内,一旦开启了事务,代表着进入了事务状态,后续输入的所有命令都将被加入事务命令队列,而不是立即执行。
2.2 EXEC(提交事务)
EXEC命令:用于提交事务。提交事务代表着将当前事务命令队列中的命令交给redis一并执行。
2.3 DISCARD(放弃事务)
DISCARD命令:用于放弃事务。放弃事务代表着销毁当前事务命令队列,不进行任何操作,同时当前客户端退出事务状态。
2.4 WATCH
WATCH命令:用于监视key的变化。由于redis支持多用户,通常在执行事务的过程中,不希望其它的用户修改我们正在操作的key。redis出于并发性能的考虑,不支持悲观锁的机制(通过阻塞或者报错来阻止其它用户修改上锁的数据),而是采用了类似乐观锁的机制。redis提供了WATCH命令来实现事务的“检查再设置”(CAS)行为,WATCH命令可以同时监听多个key的变化,在事务执行过程中一旦发现被监听的key被修改过,将会放弃执行事务,这时应该由用户来进行重试。
2.5 UNWATCH
UNWATCH命令:用于解除WATCH状态。UNWATCH之后,当前客户端将解除所有的WATCH监听。
在事务执行过程中可能会出现错误,redis将错误分为两类区别对待。
1.语法错误(编译时错误)
语法错误,即redis执行的命令本身就是错误的,这类错误可以在事务真正执行之前就被发现,例如参数不符合规范等。如同通用编程语言的编译时错误,由于这样的错误应当通过仔细的检查来完全避免,因此,redis在发现事务中存在语法错误时,会直接放弃整个事务。
2.非语法错误(运行时错误)
非语法错误,即redis无法在真正执行命令之前发现的错误。例如"incr"命令要求数据必须是数字类型,而是否是数字类型,取决于运行时的状态。如同通用编程语言的运行时错误,这样的错误通常无法完全避免,因此,redis在发现命令存在非语法错误时,不会影响事务中其它命令的正常执行。
在Redis中,事务总是具有原子性(Atomicity)、一致性(Consistency)、和隔离性(Isolation)的,并且当Redis运行在一些特定的持久化模式下,事务也具有耐久性(Durability)。
事务具有原子性是指,数据库事务中将多个操作看做一个整体来执行,要么执行所有的操作,要么一个操作也不执行。
首先弄清楚 Redis 开始事务 multi 命令后,Redis 会为这个事务生成一个队列,每次操作的命令都会按照顺序插入到这个队列中。
这个队列里面的命令不会被马上执行,直到 exec 命令提交事务,所有队列里面的命令会被一次性,并且排他的进行执行。
对于Redis的事务来说,事务队列中的命令要么都执行,要么就一个也不执行,因此,Redis的事务是具有原子性的。
Redis的事务和一般关系型数据库事务最大的区别在于Redis不支持事务回滚机制。即使事务队列中的某个命令在执行中出现了错误,整个事务也会继续执行下去,知道事务队列中的命令执行完毕。
事务具有一致性是指,如果数据库在执行事务之前是一致的,那么在执行事务之后,无论事务是否执行成功,数据库也仍一致的。
Redis通过谨慎的错误检测和简单的设计来保证了数据库的一致性。以下介绍三个Redis事务可能出错的地方,并说明Redis是如何妥善的处理这些错误,从而保证了数据的一致性。
1、入队错误
如果一个事务在入队过程中,出现了命令不存在,或者命令格式不正确等情况,Redis将拒绝这个事务;
2、执行错误
在执行事务总,错误的命令被识别出来,并且不会影响其他命令,错误的命令不会对数据做任何修改,所以Redis的一致性不会被影响。
3、宕机
无论是采用RDB或者AOF持久化方案,都可以使用RDB文件或者AOF文件进行数据恢复,从而将数据库还原至一个一致的状态。
隔离性是指,数据库中有多个事务并发的执行,各个事务之间不会相互影响,并且在并发状态下执行的事务和串行执行的事务产生的结果是完全相同的。
Redis 因为是单线程操作,所以在隔离性上有天生的隔离机制,当 Redis 执行事务时,Redis 的服务端保证在执行事务期间不会对事务进行中断,所以,Redis 事务总是以串行的方式运行,事务也具备隔离性。
事务的持久性是指,当一个事务执行完毕,执行这个事务所得到的结果被保存在持久化的存储中,即使服务器在事务执行完成后停机了,执行的事务的结果也不会被丢失。
因为Redis事务只不过是简单的用队列包裹了一组Redis命令,Redis并没有为事务提供额外的持久化功能,所以Redis的持久性取决于Redis的持久化模式。
纯内存运行,不具备持久化,服务一旦停机,所有数据将丢失。
RDB 模式,取决于 RDB 策略,只有在满足策略才会执行 BGSAVE,异步执行并不能保证 Redis 具备持久化。
AOF 模式,只有将 appendfsync 选项设置为 always,程序才会在执行命令同步保存到磁盘,这个模式下,Redis 具备持久性。当选项值为everysec,程序每秒同步一次命令到磁盘,宕机可能发生在等待同步的那一秒内,可能会造成数据丢失,这种配置下Redis不具备持久性。当选项值为no,程序交由操作系统来觉得合适同步命令到硬盘,这种配置也可能造成数据丢失,也不具备持久性。
如果你有使用关系式数据库的经验, 那么 “Redis 在事务失败时不进行回滚,而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。
以下是这种做法的优点:
当执行 DISCARD 命令时, 事务会被放弃, 事务队列会被清空, 并且客户端会从事务状态中退出
WATCH 命令可以为 Redis 事务提供 check-and-set (CAS)行为。
被 WATCH 的键会被监视,并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了, 那么整个事务都会被取消, EXEC 返回nil-reply来表示事务已经失败。
举个例子, 假设我们需要原子性地为某个值进行增 1 操作(假设 INCR 不存在)。
首先我们可能会这样做:
val = GET mykey
val = val + 1
SET mykey $val
上面的这个实现在只有一个客户端的时候可以执行得很好。 但是, 当多个客户端同时对同一个键进行这样的操作时, 就会产生竞争条件。举个例子, 如果客户端 A 和 B 都读取了键原来的值, 比如 10 , 那么两个客户端都会将键的值设为 11 , 但正确的结果应该是 12 才对。
有了 WATCH , 我们就可以轻松地解决这类问题了:
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
使用上面的代码, 如果在 WATCH 执行之后, EXEC 执行之前, 有其他客户端修改了 mykey 的值, 那么当前客户端的事务就会失败。 程序需要做的, 就是不断重试这个操作, 直到没有发生碰撞为止。
这种形式的锁被称作乐观锁, 它是一种非常强大的锁机制。 并且因为大多数情况下, 不同的客户端会访问不同的键, 碰撞的情况一般都很少, 所以通常并不需要进行重试。
WATCH 使得 EXEC 命令需要有条件地执行: 事务只能在所有被监视键都没有被修改的前提下执行, 如果这个前提不能满足的话,事务就不会被执行。 了解更多->
WATCH 命令可以被调用多次。 对键的监视从 WATCH 执行之后开始生效, 直到调用 EXEC 为止。
用户还可以在单个 WATCH 命令中监视任意多个键, 就像这样:
redis> WATCH key1 key2 key3
OK
当 EXEC 被调用时, 不管事务是否成功执行, 对所有键的监视都会被取消。
另外, 当客户端断开连接时, 该客户端对键的监视也会被取消。
使用无参数的 UNWATCH 命令可以手动取消对所有键的监视。 对于一些需要改动多个键的事务, 有时候程序需要同时对多个键进行加锁, 然后检查这些键的当前值是否符合程序的要求。 当值达不到要求时, 就可以使用 UNWATCH 命令来取消目前对键的监视, 中途放弃这个事务, 并等待事务的下次尝试。
WATCH 可以用于创建 Redis 没有内置的原子操作。举个例子, 以下代码实现了原创的 ZPOP 命令, 它可以原子地弹出有序集合中分值(score)最小的元素:
WATCH zset
element = ZRANGE zset 0 0
MULTI
ZREM zset element
EXEC
程序只要重复执行这段代码, 直到 EXEC 的返回值不是nil-reply回复即可。