Python：深入理解Redis事务

1. 从数据库事务说起

通常我们提及数据库都不可避免的要提到事务，那么什么是事务呢?事务是指作为单个逻辑工作单元执行的一系列操作。所以，首先事务是一系列操作，这一系列操作具有二态性，即完全地执行或者完全地不执行。因此事务处理可以确保除非事务单元内的所有操作的成功完成，否则不会想数据库更新面向数据的资源。我们这里举一个例子，数据库中除查询操作以外，插入(Insert)、删除(Delete)和更新(Update)这三种操作都会对数据造成影响，因为事务处理能够保证一系列操作可以完全地执行或者完全不执行，因此在一个事务被提交以后，该事务中的任何一条SQL语句在被执行的时候，都会生成一条撤销日志(Undo Log)，而撤销日志中记录的是和当前擦作完全相反的操作，比如删除的相反操作是插入，插入的相反操作是删除等。我们通常所说的事务回滚其实就是去执行这些插销日志里的相反操作，这同样告诉我们一个道理，只有事务中的一系列操作完全执行的情况下可以回滚，如果是在意外情况下导致事务中的一系列操作没有完全执行，这个时候我们是不能保证数据一定可以回滚的。

创新互联建站服务项目包括乐山网站建设、乐山网站制作、乐山网页制作以及乐山网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，乐山网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到乐山省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

在数据库相关理论中，一个逻辑工作单元想要成为事务，就必须满足 ACID，即原子性、一致性、隔离性和持久性。

• (1)原子性：原子性这个概念其实就是指，一个事务内的所有SQL操作都是一个整体，因此只有所有的SQL操作都完全执行成功，该事务方可以认为提交成功。如果在提交事务过程中某一条SQL语句执行失败，则整个事务必须回滚到事务提交前的状态。
• (2)一致性：而一致性这个概念则是指，事务在完成的时候，必须要保证所有的数据都保持一致的状态，而落实到数据库的各个组成部分上，则要求开发人员能够保证数据、索引、约束、日志等在事务前后具备一致性。
• (3)隔离性：隔离性这个概念主要针对并发，其核心思想就是不同的并发事务对数据产生的修改必须是相互隔离的，假设有两个不同的事务A和B并发执行，那么对A来讲，它在执行前的状态只有两种，即B执行前和B执行后。同理，对B来讲同样是如此，这样的特性我们就称为隔离性。
• (4)持久性：持久性相对简单，是指事务完成以后它对数据的影响是永久性的。

2. redis中的事务处理

我们对数据库中事务处理的相关理论有了一个基本的认识，或许这个世界上的数据库系统千差万别，但我相信在事务处理这个问题上它们最终会殊途同归，就像我们解决并发过程中的冲突问题，常规的做法依然是加锁一样，这是我之所以要花费精力去理解和解释这些理论知识的原因，技术可谓是日新月异，如果我们总是一味地为新技术而疲于奔命，那么或许我们会渐渐地失去对这个行业的热爱，我相信原理永远比框架更为重要。

redis事务提供了一种“将多个命令打包， 然后一次性、按顺序地执行”的机制， 并且事务在执行的期间不会主动中断 —— 服务器在执行完事务中的所有命令之后， 才会继续处理其他客户端的其他命令。

Redis中的事务是可以视为一个队列，即我们可以通过MULTI开始一个事务，这相当于我们声明了一个命令队列。接下来，我们向Redis中提交的每条命令，都会被排入这个命令队列。当我们输入EXEC命令时，将触发当前事务，这相当于我们从命令队列中取出命令并执行，所以Redis中一个事务从开始到执行会经历  开始事务 、  命令入队 和  执行事务 三个阶段。下面是一个在Redis中使用事务的简单示例：

127
.0
.0
.1
:6379> 
MULTI 
OK 
127
.0
.0
.1
:6379> 
SET 
Book_Name "
GIt 
Pro" 
QUEUED 
127
.0
.0
.1
:6379> 
SADD 
Program_Language "
C++" "
C#" "
Jave" "
Python"  
QUEUED 
127
.0
.0
.1
:6379> 
GET 
Book_Name 
QUEUED 
127
.0
.0
.1
:6379> 
EXEC 
1) 
OK 
2) (
integer) 4 
3) "
GIt 
Pro" 

我们可以注意到Redis中的事务和通常意义上的事务基本上是一致的，即

• 事务是由一系列操作组成的单个逻辑工作执行单元。特别地，因为在Redis中命令是存储在一个队列中，所以，事务中的所有命令都会按顺序执行，并且在执行事务的过程中不会被客户端发送的其它命令中断。
• 事务是一个原子操作，事物中的命令只有两种执行结果，即全部执行或者全部不执行。如果客户端在使用MULTI命令开启事务后因为意外而没有执行EXEC命令，则事务中的所有命令都不会执行。同理，如果客户端在使用MULTI命令开启事务后执行EXEC命令，则事务中的所有命令都会执行。
• Redis中的事务可以使用DISCARD命令来清空一个命令队列，并放弃对事务的执行。如果命令在入队时发生错误，Redis将在客户端调用EXEC命令时拒绝执行并取消事务，但是在EXEC命令执行后发生的错误，Redis将选择自动忽略。

3.redis事务执行过程

一个事务从开始到执行会经历以下三个阶段：

• 1）开始事务。
• 2）命令入队。
• 3）执行事务。

下面将分别介绍事务的这三个阶段。

1）开始事务

MULTI命令的执行标记着事务的开始：

redis>
 MULTI
OK

这个命令唯一做的就是， 将客户端的 REDIS_MULTI 选项打开， 让客户端从非事务状态切换到事务状态。

图1 客户端状态转换

2）命令入队

当客户端处于非事务状态下时， 所有发送给服务器端的命令都会立即被服务器执行：

redis>
 SET msg 
"hello moto"
OK

redis> GET msg
"hello moto"

但是， 当客户端进入事务状态之后， 服务器在收到来自客户端的命令时， 不会立即执行命令， 而是将这些命令全部放进一个事务队列里， 然后返回QUEUED， 表示命令已入队：

redis>
 MULTI
OK

redis> SET msg 
"hello moto"
QUEUED

redis> GET msg
QUEUED

其原理如图2所示

图2. 命令入队

3）执行事务

前面说到， 当客户端进入事务状态之后， 客户端发送的命令就会被放进事务队列里。

但其实并不是所有的命令都会被放进事务队列， 其中的例外就是 EXEC 、 DISCARD 、 MULTI 和 WATCH 这四个命令 —— 当这四个命令从客户端发送到服务器时， 它们会像客户端处于非事务状态一样， 直接被服务器执行：

图3 执行事务

如果客户端正处于事务状态， 那么当EXEC命令执行时， 服务器根据客户端所保存的事务队列， 以先进先出（FIFO）的方式执行事务队列中的命令： 最先入队的命令最先执行， 而最后入队的命令最后执行。

执行事务中的命令所得的结果会以 FIFO 的顺序保存到一个回复队列中。

当事务队列里的所有命令被执行完之后，EXEC命令会将回复队列作为自己的执行结果返回给客户端， 客户端从事务状态返回到非事务状态， 至此， 事务执行完毕。

4.redis事务命令

redis事务使用了multi、exec、discard、watch、unwatch命令，命令的作用如图4所示：

图4 事务命令

使用案例：

• 正常执行

图5. 正常执行

• 放弃事务

图6 放弃事务

• 若在事务队列中存在命令性错误，则执行EXEC命令时，所有命令都不会执行

图7 命令错误

• 若在事务队列中存在语法性错误，则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。

图8 语法错误

• 使用watch

使用watch检测balance，事务期间balance数据未变动，事务执行成功

图9 watch用法1

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

图10 watch用法2

图11 修改balance

• WATCH 命令的实现

在每个代表数据库的 redis.h/redisDb 结构类型中， 都保存了一个 watched_keys 字典， 字典的键是这个数据库被监视的键， 而字典的值则是一个链表， 链表中保存了所有监视这个键的客户端。

比如说，以下字典就展示了一个 watched_keys 字典的例子：

图11 watch实现的原理

其中， 键 key1 正在被 client2 、 client5 和 client1 三个客户端监视， 其他一些键也分别被其他别的客户端监视着。

WATCH 命令的作用， 就是将当前客户端和要监视的键在 watched_keys 中进行关联。

举个例子， 如果当前客户端为 client10086 ， 那么当客户端执行 WATCH key1 key2 时， 前面展示的 watched_keys 将被修改成这个样子：

图12 watch实现原理2

通过watched_keys字典， 如果程序想检查某个键是否被监视， 那么它只要检查字典中是否存在这个键即可； 如果程序要获取监视某个键的所有客户端， 那么只要取出键的值（一个链表）， 然后对链表进行遍历即可。

• watch的触发
  在任何对数据库键空间（key space）进行修改的命令成功执行之后 （比如FLUSHDB、SET、DEL、LPUSH、SADD、ZREM，诸如此类），multi.c/touchWatchedKey函数都会被调用 —— 它检查数据库的watched_keys字典， 看是否有客户端在监视已经被命令修改的键， 如果有的话， 程序将所有监视这个/这些被修改键的客户端的REDIS_DIRTY_CAS选项打开：

图13 watch的触发

当客户端发送 EXEC 命令、触发事务执行时， 服务器会对客户端的状态进行检查：

• 如果客户端的 REDIS_DIRTY_CAS 选项已经被打开，那么说明被客户端监视的键至少有一个已经被修改了，事务的安全性已经被破坏。服务器会放弃执行这个事务，直接向客户端返回空回复，表示事务执行失败。
• 如果 REDIS_DIRTY_CAS 选项没有被打开，那么说明所有监视键都安全，服务器正式执行事务。

5.  事务的 ACID 性质

在Redis中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当Redis运行在某种特定的持久化模式下，事务也具有持久性性（Durability）。

• 原子性

事务具有原子性指的是， 数据库将事务中的多个操作当作一个整体来执行，服务器要么就执行事务中的所有操作， 要么就一个操作也不执行。对于Redis的事务功能来说，事务队列中的命令要么就全部都执行，要么就一个都不执行，因此， Redis的事务是具有原子性的。

Redis的事务和传统的关系型数据库事务的最大区别在于， Redis不支持事务回滚机制(rollback)， 即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到将事务队列中的所有命令都执行完毕为止。 下面展示了即使RPUSH命令在执行期间出现了错误，事务的后续命令也会继续执行下去， 并且之前执行的命令也不会有任何影响：

127
.0
.0
.1
:6379> 
set 
msg 
hello
OK

127
.0
.0
.1
:6379> 
multi
OK

127
.0
.0
.1
:6379> 
sadd 
fruit 
apple 
banana 
cherry
QUEUED

127
.0
.0
.1
:6379> 
rpush 
msg 
bye 
redis
QUEUED

127
.0
.0
.1
:6379> 
sadd 
alphabet 
a 
b 
c
QUEUED

127
.0
.0
.1
:6379> 
exec
1) (
integer) 3
2) (
error) 
WRONGTYPE 
Operation 
against 
a 
key 
holding 
the 
wrong 
kind 
of 
value
3) (
integer) 3

不支持事务回滚是因为这种复杂的功能和Redis追求简单高效的设计主旨不相符，并且Redis事务的执行时错误通常都是编程错误产生的， 这种错误通常只会出现在开发环境中， 而很少会在实际的生产环境中出现。

• 一致性

事务的一致性是指，如果数据库执行前是一致的，那么在事务执行后，无论事务是否执行成功，数据库也应该是一致的。

• 隔离性
  事务的隔离性指的是，即使数据库中有多个事务并发地执行，各个事务之间也不会互相 影响，并且在并发状态下执行的事务和串行执行的事务产生的结果完全相同。
  因为Redis使用 单线程的方式来执行事务（以及事务队列中的命令），并且服务器保证， 在执行事务期间不会对事务进行中断，因此， Redis的事务总是以串行的方式运行的，并且  事务 也总是具有隔离性的。
• 持久性

事务的耐久性指的是，当一个事务执行完毕时，执行这个事务所得的结果巳经被保存到 永久性存储介质（比如硬盘）里面了， 即使服务器在事务执行完毕 之后停机， 执行事务所得的结果也不会丢失。Redis事务的耐久性由服务器所使用持久化模式决定的：(1) 当服务器在无持久化的内存模式下运作时，事务不具有耐久性。因为一旦服务器停机，服务器所有的数据都将丢失。(2) 当服务器在ROB持久化模式下运作时，事务同样不具有耐久性。因为服务器只会在特定的保存条件下才会执行BGSAVE命令，并且异步执行的BGSAVE命令不能保证事务的数据第一时间被保存到硬盘上。(3) 当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，程序总会在执行命令之后调用同步(sync)函数，将命令数据真正地保存到硬盘里。