Redis学习笔记 - 事务

最新推荐文章于 2023-03-08 19:27:51 发布

mytt_10566

最新推荐文章于 2023-03-08 19:27:51 发布

阅读量558

点赞数

分类专栏： redis 文章标签： redis redis事务事务

本文链接：https://blog.csdn.net/mytt_10566/article/details/99618505

版权

redis 专栏收录该内容

23 篇文章 0 订阅

订阅专栏

参考：

<<Redis设计与实现>>
- 注：这本书是基于Redis3.0版本写的，和后面的版本有点差异
http://www.redis.cn/topics/transactions.html

Redis通过MULTI、EXEC、WATCH等命令来实现事务（transaction）功能。

事务提供了一种将多个命令请求打包，然后一次性、按顺序执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而去执行其他客户端的命令请求，它会将事务中所有命令都执行完，然后再去执行其他命令请求。

示例：

事务首先以MULTI命令开始，接着将多个命令放入事务当中，最后由EXEC命令将这个事务提交（commit）给服务器执行。

redis> MULTI
OK

redis> set num1 1
QUEUED
redis> get num1
QUEUED
redis> set num2 2
QUEUED
redis> get num2
QUEUED

redis> EXEC
1) OK
2) "1"
3) OK
4) "2"

下面介绍Redis如何使用MULTI、EXEC命令实现事务功能及实现原理，WATCH命令的作用及其实现原理，Redis事务的ACID性质。

一、事务的实现

一个事务从开始到结束通常经历下面三个阶段：

事务开始
命令入队
事务执行

1.1 事务开始

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

redis> MULTI
OK

MULTI命令可以将执行该命令的客户端从非事务状态进入事务状态，这一改变是通过在客户端状态的flags属性中打开REDIS_MULTI标识来完成的。

1.2 命令入队

当一个客户端处于非事务状态时，这个客户端发送的命令会立即被服务器执行。当客户端切换到事务状态后，服务器会根据发来的不同命令执行不同的操作：

如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI 4个命令其中之一，那么服务器立即执行命令
如果是其他命令，服务器不立即执行，而是将命令放入一个事务队列里，然后向客户端返回QUEUED回复

1.3 事务队列

每个客户端都有自己的事务状态，这个事务状态保存在客户端状态的mstate属性里：

typedef struct redisClient {
	// ...
	// 事务状态，MULTI/EXEC state
	multiState mstate;
	// ...
}

事务状态包含一个事务队列，以及一个已入队列命令的计数器（事务队列的长度）：

typedef struct multiState {
	// 事务队列，FIFO顺序
	multiCmd *commands;
	// 已如队命令计数
	int count;
} multiState;

事务队列是一个multiCmd类型的数组，数组中每个multiCmd结构都保存了一个已入队列命令的相关信息，包括指向命令实现函数的指针、命令的参数、参数的数量：

typedef struct multiCmd {
	// 参数
	robj **argv;
	// 参数数量
	int argc;
	// 命令指针
	struct redisCommand *cmd;
}

事务队列以先进先出（FIFO）的方式保存入队列的命令，较先入队的命令会被放到数组的前面，后入队列的命令会被放到数组的后面。

示例，客户端执行以下命令：

redis> MULTI
OK

redis> set name "xxx"
QUEUED
redis> get name
QUEUED

redis> set author "xxx"
QUEUED
redis> get author
QUEUED

此时，服务器为客户端创建以下事务状态：

最先入队列的SET命令放在了事务队列的索引0位置上
第二个入队列的GET命令放在事务队列的索引1位置上
之后的SET、GET命令依次放在索引2、3位置上

事务状态如下图所示：

1.4 执行事务

当一个处于事务状态的客户端向服务器发送EXEC命令时，这个EXEC命令将立即被服务器执行。

服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后执行命令所得的结果全部返回给客户端。

执行事务流程如下图所示：

二、WATCH命令的实现

WATCH命令是一个乐观锁（optimistic locking），它可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC命令执行时，检查被监视的键是否至少有一个已经被修改过了，如果是，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。

示例，一个事务执行失败的例子：

redis> WATCH name
OK

redis> MULTI
OK

reids> SET name peter
QUEUED

redis> EXEC
(nil)

下表展示了上面的事务是如何失败的：

有客户端A、B执行命令，在时间T4时，客户端B修改了name键的值
客户端A在T5执行EXEC命令时，服务器会发现WATCH监视的键name已经被修改，因此服务器拒绝执行客户端A的事务，并向客户端A返回空回复

2.1 使用WATCH命令监视数据库键

每个Redis数据库都保存一个watched_keys字典，这个字典的键是某个被WATCH命令监视的数据库键，而字典的值是一个链表，链表中记录了所有监视相应数据库键的客户端：

typedef struct redisDb {
	// ...
	// 正在被WATCH命令监视的键
	dict *watched_keys;
	// ...
} redisDb;

通过watched_keys字典，服务器可以清楚知道哪些数据库键正在被监视，以及哪些客户端正在监视这些数据库键。

示例：

客户端c1、c2监视键name；客户端c3监视键age；客户端c2、c4监视键address

watched_keys字典结构如下图所示：

2.2 监视机制的触发

所有对数据库进行修改的命令，如SET、LPUSH、SADD、ZREM、DEL、FLUSHDB等，在执行后都会调用multi.c/touchWatchKey函数对watched_keys字典进行检查
查看是否有客户端正在监视刚刚被命令修改过的数据库键，如果有，那么touchWatchKey函数会将监视被修改键的客户端的REDIS_DIRTY_CAS标识打开，表示该客户端的事务安全性已经被破坏

示例：

如2.1中watched_keys字典所示，假如键"name"被修改，那么c1、c2两个客户端的REDIS_DIRTY_CAS标识被打开。

检查过程的流程如下图所示：
检查过程流程

2.3 判断事务是否安全

当服务器收到一个客户端发来的EXEC命令时，服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务：

如果客户端的REDIS_DIRTY_CAS标识已经打开，说明客户端所监视的键中至少有一个被修改了，在这种情况下，客户端提交的事务已经不再安全，所以服务器会拒绝执行客户端提交的事务
如果客户端的REDIS_DIRTY_CAS标识没有打开，说明客户端监视的所有键都没有被修改过（或客户端没有监视任何键），事务仍然是安全的，服务器会会执行客户端提交的事务

判断是否执行事务的过程如下图所示：

2.4 一个完整的WATCH事务执行过程

示例：一个带有WATCH的事务从开始到失败的整个过程

假设当前客户端为c10086，而数据库watched_keys字典的当前状态如下图所示：

当c10086执行WATCH命令后，watched_keys字典会更新到下图所示的状态：

redis> WATCH name
OK

watched_keys字典会更新后的状态

接下来，客户端c10086继续向服务器发送MULTI命令，并将一个SET命令放入事务队列：

redis> MULTI
OK
redis> SET name peter
QUEUED

这时，另一个客户端c999向服务器发送一条SET命令，将"name"键的值设置成"join"：

redis> SET name john
OK

c999执行的SET命令会导致正在监视"name"键的所有客户端的REDIS_DIRTY_CAS标识被打开，包括c10086客户端。
之后，当c10086向服务器发送EXEC命令时，因为客户端的REDIS_DIRTY_CAS标识被打开，所以服务器拒绝执行它提交的事务

redis> EXEC
(nil)

三、事务的ACID性质

在传统的关系型数据库中，用ACID性质来检查事务功能的可靠性和安全性。

在Redis中，事务总是有原子性（Atomictiy）、一致性（Consistency）、隔离性（Isolation），当Redis运行在RDB / AOF持久化模式下时，事务也具有持久性（Durability）。

3.1 原子性

原子性：数据库将事务中的多个操作当作一个整体来执行，服务器要么执行事务中所有操作，要么就一个也不执行。

对于Redis的事务功能来说，事务队列中的命令要么全部执行，要么一个也不执行。因此，Redis的事务是具有原子性的。

示例：

（1）执行成功的事务

redis> MULTI
OK

redis> SET msg hello
QUEUED

redis> GET msg
QUEUED

redis> EXEC
1) OK
2) "hello"

（2）执行失败的事务

这个事务因为命令入队出错而被服务器拒绝执行，事务中所有命令都不会被执行：

redis> MULTI
OK

redis> SET msg hello
QUEUED

redis> GET
(error) ERR wrong number of arguments for 'get' command

redis> GET msg
QUEUED

redis> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

（3）执行期间出现错误的事务

Redis和传统的关系型数据库事务最大区别在于：

Redis不支持事务回滚机制（rollback），即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，知道将事务队列的所有命令都执行完毕。

Redis事务功能的文档有说明：（http://www.redis.cn/topics/transactions.html）
不支持事务回滚是因为这种复杂的功能和Redis追求简单高效的设计不相符，并且Redis事务的执行错误通常是编程错误产生，这种错误只会出现在开发环境中，在实际的生产环境中很少出现，所以Redis没有必要支持事务回滚功能。

下面的示例中，即使RPUSH命令在执行期间出现了错误，事务的后续命令也会继续执行下去，之前执行的命令也不受到影响。

redis> SET msg hello  # 字符换键
OK

redis> MULTI
OK

redis> SADD fruit apple banana cherry
QUEUED

redis> RPUSH msg 'good bye'
QUEUED

redis> SADD abc a b c
QUEUED

redis> EXEC
1) (integer) 3
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) (integer) 3

3.2 一致性

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

一致：指的是数据库本身的定义和要求，没有包含非法或无效的错误数据。

Redis保证事务一致性示例：

（1）入队错误

如果一个事务在入队命令的过程中，出现了命令不存在、命令格式不正确等情况，那么Redis将拒绝执行这个事务。

下面的示例，因为客户端尝试向事务入队一个不存在的命令：MYCOMMD，所以客户端提交的事务会被服务器决绝执行：

redis> MULTI
OK

redis> SET msg hello
QUEUED

redis> MYCOMMD
(error) ERR unknown command `MYCOMMD`, with args beginning with:

redis> GET msg
QUEUED

redis> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

注：

因为服务器会拒绝执行入队过程中出现错误的事务，所以Redis事务一致性不会被破坏。
在Redis2.6.5及之后的版本，如果出现上面的情况，服务器是拒绝执行事务命令的。在之前的版本中，可以正常执行成功入队的命令，忽略入队失败的，如上面例子中的MYCOMMD。因为错误的命令不会入队，所以Redis只是执行入队的命令，这样，Redis的事务一致性也不会被破坏。

（2）执行错误

事务还可能在执行过程中发生错误：

执行过程中发生的错误都是一些不能入队时被服务器发现的错误，这些错误只会在命令实际执行时被触发
即使在事务的执行过程中发生了错误，服务器也不会中断事务的执行，继续执行事务中余下的命令，已执行的命令（包括执行结果）不会被出错的命令影响

示例：

在执行过程中，出错的命令被服务器找出来并进行相应的处理，所以这些出错命令不会对数据库做任何修改，也不会破坏事务的一致性。

redis> SET msg hello  # 字符换键
OK

redis> MULTI
OK

redis> SADD fruit apple banana cherry
QUEUED

redis> RPUSH msg 'good bye'
QUEUED

redis> SADD abc a b c
QUEUED

redis> EXEC
1) (integer) 3
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) (integer) 3

（3）服务器停机

如果Redis服务器在执行事务的过程中停机，根据服务器所使用的持久化模式，可能出现以下几种情况：

服务器运行在无持久化的内存模式下，那么重启后的数据库会是空白的，因此数据总是一致的。
服务器运行在RDB持久化模式下，事务中途停机不会导致不一致，因为服务器可以根据现有的RDB文件来恢复数据，将数据库还原到一个一致的状态。如果找不到RDB文件，那么重启后数据库是空白的，空白数据库是一致的。
服务器运行在AOF持久化模式下，事务中途停机，服务器也可以根据AOF文件恢复数据，恢复数据到一个一致的状态。如果找不到AOF文件，那么数据库空白，空白数据库是一致的。

所以不管Redis服务器运行在哪种持久化模式下，事务执行中途发生停机都不会影响数据库一致性。

3.3 隔离性

隔离性：即使数据库中有多个事务并发地执行，各个事务之间也不会互相影响，并且在并发状态下执行的事务和串行执行的事务产生的结果完全相同。

因为Redis使用单线程的方式来执行事务（以及事务队列中的命令），并且服务器保证，在执行期间不会对事务进行中断，因此，Redis事务总是以串行方式运行并且事务具有隔离性。

3.4 持久性

持久性：当一个事务执行完毕后，执行这个事务的结果被持久化了（如硬盘），即使服务器在事务执行结束后停机，执行事务的结果也不会丢失。

Redis的事务只是简单打包了一组Redis命令，没有为事务提供额外持久化功能，所以Redis事务的持久性依赖于Redis所使用的持久化方式。

当服务器在无持久化模式下运行，事务不具备持久性：服务器停机，所有服务器数据都会丢失
RDB持久化：服务器只会在保存条件满足时，才会执行BGSAVE命令，对数据库执行保存操作，并且异步执行的BGSAVE不能保证事务数据立即保存到硬盘里，所以事务不具备持久性
AOF持久化：
- appendfsync选项值为always：程序会在执行命令后调用同步（sync）函数，将命令数据保存到硬盘里，所以具备持久性
- appendfsync选项值为everysec：程序每秒同步一次数据到硬盘，因此停机正好发生在等待同步的那一秒钟内，会造成事务数据丢失，所以这种配置不具备持久性
- appendfsync选项值为no：程序将数据同步到硬盘这个操作交由操作系统来决定。所以事务数据可能在等待同步过程中丢失，这种配置下也不具备持久性

注：

不论Redis在什么模式下运行，在一个事务最后加上SAVE命令，可以保证事务的持久性。不过这种做法效率低，不实用。

mytt_10566

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis学习笔记 - 事务

参考：<<Redis设计与实现>>注：这本书是基于Redis3.0版本写的，和后面的版本有点差异http://www.redis.cn/topics/transactions.htmlRedis通过MULTI、EXEC、WATCH等命令来实现事务（transaction）功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序执行多个命令的机制，并且在...
复制链接

扫一扫