redis——事务
Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：
- 批量操作在发送 EXEC 命令前被放入队列缓存。
- 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
- 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。
一个事务从开始到执行会经历以下三个阶段：
- 开始事务。
- 命令入队。
- 执行事务。
以下是一个事务的例子， 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：
-
redis 127.0.0.1:6379> MULTI
-
OK
-
-
redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
-
QUEUED
-
-
redis 127.0.0.1:6379> GET book-name
-
QUEUED
-
-
redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
-
QUEUED
-
-
redis 127.0.0.1:6379> SMEMBERS tag
-
QUEUED
-
-
redis 127.0.0.1:6379> EXEC
-
1) OK
-
2) "Mastering C++ in 21 days"
-
3) (integer) 3
-
4) 1) "Mastering Series"
-
2) "C++"
-
3) "Programming"
详细介绍：
事务开始
MULTI 命令的执行标志着事务的开始：
-
redis> MULTI
-
OK
MULTI 命令可以将执行该命令的客户端从非事务状态切换至事务状态， 这一切换是通过在客户端状态的 flags 属性中打开 REDIS_MULTI 标识来完成的， MULTI 命令的实现可以用以下伪代码来表示：
-
def MULTI():
-
-
# 打开事务标识
-
client.flags |= REDIS_MULTI
-
-
# 返回 OK 回复
-
replyOK()
命令入队
当一个客户端处于非事务状态时， 这个客户端发送的命令会立即被服务器执行：
redis> SET "name" "Practical Common Lisp" OK redis> GET "name" "Practical Common Lisp" redis> SET "author" "Peter Seibel" OK redis> GET "author" "Peter Seibel"
与此不同的是， 当一个客户端切换到事务状态之后， 服务器会根据这个客户端发来的不同命令执行不同的操作：
- 如果客户端发送的命令为 EXEC 、 DISCARD 、 WATCH 、 MULTI 四个命令的其中一个， 那么服务器立即执行这个命令。
- 与此相反， 如果客户端发送的命令是 EXEC 、 DISCARD 、 WATCH 、 MULTI 四个命令以外的其他命令， 那么服务器并不立即执行这个命令， 而是将这个命令放入一个事务队列里面， 然后向客户端返回
QUEUED回复。
事务队列
每个 Redis 客户端都有自己的事务状态， 这个事务状态保存在客户端状态的 mstate 属性里面：
-
typedef struct redisClient {
-
-
// ...
-
-
// 事务状态
-
multiState mstate; /* MULTI/EXEC state */
-
-
// ...
-
-
} redisClient;
事务状态包含一个事务队列， 以及一个已入队命令的计数器 （也可以说是事务队列的长度）：
-
typedef struct multiState {
-
-
// 事务队列，FIFO 顺序
-
multiCmd *commands;
-
-
// 已入队命令计数
-
int count;
-
-
} multiState;
事务队列是一个 multiCmd 类型的数组， 数组中的每个 multiCmd 结构都保存了一个已入队命令的相关信息， 包括指向命令实现函数的指针， 命令的参数， 以及参数的数量：
-
typedef struct multiCmd {
-
-
// 参数
-
robj **argv;
-
-
// 参数数量
-
int argc;
-
-
// 命令指针
-
struct redisCommand *cmd;
-
-
} multiCmd;
事务队列以先进先出（FIFO）的方式保存入队的命令： 较先入队的命令会被放到数组的前面， 而较后入队的命令则会被放到数组的后面。
举个例子， 如果客户端执行以下命令：
redis> MULTI OK redis> SET "name" "Practical Common Lisp" QUEUED redis> GET "name" QUEUED redis> SET "author" "Peter Seibel" QUEUED redis> GET "author" QUEUED
那么服务器将为客户端创建事务状态：
- 最先入队的 SET 命令被放在了事务队列的索引
0位置上。 - 第二入队的 GET 命令被放在了事务队列的索引
1位置上。 - 第三入队的另一个 SET 命令被放在了事务队列的索引
2位置上。 - 最后入队的另一个 GET 命令被放在了事务队列的索引
3位置上。
执行事务
当一个处于事务状态的客户端向服务器发送 EXEC 命令时， 这个 EXEC 命令将立即被服务器执行： 服务器会遍历这个客户端的事务队列， 执行队列中保存的所有命令， 最后将执行命令所得的结果全部返回给客户端。
EXEC 命令的实现原理可以用以下伪代码来描述：
-
def EXEC():
-
-
# 创建空白的回复队列
-
reply_queue = []
-
-
# 遍历事务队列中的每个项
-
# 读取命令的参数，参数的个数，以及要执行的命令
-
for argv, argc, cmd in client.mstate.commands:
-
-
# 执行命令，并取得命令的返回值
-
reply = execute_command(cmd, argv, argc)
-
-
# 将返回值追加到回复队列末尾
-
reply_queue.append(reply)
-
-
# 移除 REDIS_MULTI 标识，让客户端回到非事务状态
-
client.flags &= ~REDIS_MULTI
-
-
# 清空客户端的事务状态，包括：
-
# 1）清零入队命令计数器
-
# 2）释放事务队列
-
client.mstate.count = 0
-
release_transaction_queue(client.mstate.commands)
-
-
# 将事务的执行结果返回给客户端
-
send_reply_to_client(client, reply_queue)
WATCH命令的实现
WATCH命令是一个乐观锁，它可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC执行后，检查被监视的键是否至少有一个被修改，如果是，服务器拒绝执行事务，并向客户端返回代表事务执行失败的回复。
-
/* Redis database representation. There are multiple databases identified
-
* by integers from 0 (the default database) up to the max configured
-
* database. The database number is the 'id' field in the structure. */
-
typedef struct redisDb {
-
dict *dict; /* The keyspace for this DB 数据库键空间，保存数据库中所有的键值对*/
-
dict *expires; /* Timeout of keys with a timeout set 保存过期时间*/
-
dict *blocking_keys; /* Keys with clients waiting for data (BLPOP) */
-
dict *ready_keys; /* Blocked keys that received a PUSH 已经准备好数据的阻塞状态的key*/
-
dict *watched_keys; /* WATCHED keys for MULTI/EXEC CAS 事物模块，用于保存被WATCH命令所监控的键*/
-
// 当内存不足时，Redis会根据LRU算法回收一部分键所占的空间，而该eviction_pool是一个长为16数组，保存可能被回收的键
-
// eviction_pool中所有键按照idle空转时间，从小到大排序，每次回收空转时间最长的键
-
struct evictionPoolEntry *eviction_pool; /* Eviction pool of keys */
-
// 数据库ID
-
int id; /* Database ID */
-
// 键的平均过期时间
-
long long avg_ttl; /* Average TTL, just for stats */
-
} redisDb;
在每个代表数据库的 server.h/redisDb 结构类型中， 都保存了一个 watched_keys 字典， 字典的键是这个数据库被监视的键， 而字典的值则是一个链表， 链表中保存了所有监视这个键的客户端。比如说，以下字典就展示了一个 watched_keys 字典的例子：
每个key后挂着监视自己的客户端。
监控的触发
在任何对数据库键空间（key space）进行修改的命令成功执行之后 （比如 FLUSHDB 、 SET 、 DEL 、 LPUSH 、 SADD 、 ZREM ，诸如此类）， multi.c/touchWatchedKey 函数都会被调用 （修改命令会调用signalModifiedKey()函数来处理数据库中的键被修改的情况，该函数直接调用touchWatchedKey()函数）—— 它检查数据库的 watched_keys 字典， 看是否有客户端在监视已经被命令修改的键， 如果有的话， 程序将所有监视这个/这些被修改键的客户端的 REDIS_DIRTY_CAS 选项打开：
-
/* "Touch" a key, so that if this key is being WATCHed by some client the
-
* next EXEC will fail. */
-
// Touch 一个 key，如果该key正在被监视，那么客户端会执行EXEC失败
-
void touchWatchedKey(redisDb *db, robj *key) {
-
list *clients;
-
listIter li;
-
listNode *ln;
-
-
// 字典为空，没有任何键被监视
-
if (dictSize(db->watched_keys) == 0) return;
-
// 获取所有监视这个键的客户端
-
clients = dictFetchValue(db->watched_keys, key);
-
// 没找到返回
-
if (!clients) return;
-
-
/* Mark all the clients watching this key as CLIENT_DIRTY_CAS */
-
/* Check if we are already watching for this key */
-
// 遍历所有客户端，打开他们的 REDIS_DIRTY_CAS 标识
-
listRewind(clients,&li);
-
while((ln = listNext(&li))) {
-
client *c = listNodeValue(ln);
-
-
// 设置CLIENT_DIRTY_CAS标识
-
c->flags |= CLIENT_DIRTY_CAS;
-
}
-
}
事务的ACID性质
在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的安全性。
redis事物总是具有前三个性质。
a）原子性atomicity：redis事务保证事务中的命令要么全部执行要不全部不执行。
但是redis不同于传统关系型数据库，不支持回滚，即使出现了错误，事务也会继续执行下去。
因为redis作者认为，这种复杂的机制和redis追求的简单高效不符。并且，redis事务错误通常是编程错误，只会出现在开发环境中，而不会出现在实际生产环境中，所以没必要支持回滚。
b）一致性consistency：redis事务可以保证命令失败的情况下得以回滚，数据能恢复到没有执行之前的样子，是保证一致性的，除非redis进程意外终结。
Redis 的一致性问题可以分为三部分来讨论：入队错误、执行错误、Redis 进程被终结。
入队错误
在命令入队的过程中，如果客户端向服务器发送了错误的命令，比如命令的参数数量不对，等等， 那么服务器将向客户端返回一个出错信息， 并且将客户端的事务状态设为 REDIS_DIRTY_EXEC 。
因此，带有不正确入队命令的事务不会被执行，也不会影响数据库的一致性。
执行错误
如果命令在事务执行的过程中发生错误，比如说，对一个不同类型的 key 执行了错误的操作， 那么 Redis 只会将错误包含在事务的结果中， 这不会引起事务中断或整个失败，不会影响已执行事务命令的结果，也不会影响后面要执行的事务命令， 所以它对事务的一致性也没有影响。
Redis 进程被终结
如果 Redis 服务器进程在执行事务的过程中被其他进程终结，或者被管理员强制杀死，那么根据 Redis 所使用的持久化模式，可能有以下情况出现：
内存模式：如果 Redis 没有采取任何持久化机制，那么重启之后的数据库总是空白的，所以数据总是一致的。
RDB 模式：在执行事务时，Redis 不会中断事务去执行保存 RDB 的工作，只有在事务执行之后，保存 RDB 的工作才有可能开始。所以当 RDB 模式下的 Redis 服务器进程在事务中途被杀死时，事务内执行的命令，不管成功了多少，都不会被保存到 RDB 文件里。恢复数据库需要使用现有的 RDB 文件，而这个 RDB 文件的数据保存的是最近一次的数据库快照（snapshot），所以它的数据可能不是最新的，但只要 RDB 文件本身没有因为其他问题而出错，那么还原后的数据库就是一致的。
AOF 模式：因为保存 AOF 文件的工作在后台线程进行，所以即使是在事务执行的中途，保存 AOF 文件的工作也可以继续进行，因此，根据事务语句是否被写入并保存到 AOF 文件，有以下两种情况发生：
1）如果事务语句未写入到 AOF 文件，或 AOF 未被 SYNC 调用保存到磁盘，那么当进程被杀死之后，Redis 可以根据最近一次成功保存到磁盘的 AOF 文件来还原数据库，只要 AOF 文件本身没有因为其他问题而出错，那么还原后的数据库总是一致的，但其中的数据不一定是最新的。
2）如果事务的部分语句被写入到 AOF 文件，并且 AOF 文件被成功保存，那么不完整的事务执行信息就会遗留在 AOF 文件里，当重启 Redis 时，程序会检测到 AOF 文件并不完整，Redis 会退出，并报告错误。需要使用 redis-check-aof 工具将部分成功的事务命令移除之后，才能再次启动服务器。还原之后的数据总是一致的，而且数据也是最新的（直到事务执行之前为止）。
c）隔离性Isolation：redis事务是严格遵守隔离性的，原因是redis是单进程单线程模式，可以保证命令执行过程中不会被其他客户端命令打断。
因为redis使用单线程执行事务，并且保证不会中断，所以肯定有隔离性。
d）持久性Durability：持久性是指：当一个事务执行完毕，结果已经保存在永久介质里，比如硬盘，所以即使服务器后来停机了，结果也不会丢失
redis事务是不保证持久性的，这是因为redis持久化策略中不管是RDB还是AOF都是异步执行的，不保证持久性是出于对性能的考虑。
重点提炼
- 事务提供了一种将多个命令打包， 然后一次性、有序地执行的机制。
- 多个命令会被入队到事务队列中， 然后按先进先出（FIFO）的顺序执行。
- 事务在执行过程中不会被中断， 当事务队列中的所有命令都被执行完毕之后， 事务才会结束。
- 带有 WATCH 命令的事务会将客户端和被监视的键在数据库的
watched_keys字典中进行关联， 当键被修改时， 程序会将所有监视被修改键的客户端的REDIS_DIRTY_CAS标志打开。 - 只有在客户端的
REDIS_DIRTY_CAS标志未被打开时， 服务器才会执行客户端提交的事务， 否则的话， 服务器将拒绝执行客户端提交的事务。 - Redis 的事务总是保证 ACID 中的原子性、一致性和隔离性， 当服务器运行在 AOF 持久化模式下， 并且
appendfsync选项的值为always时， 事务也具有耐久性。
文章来源: fantianzuo.blog.csdn.net，作者：兔老大RabbitMQ，版权归原作者所有，如需转载，请联系作者。
原文链接：fantianzuo.blog.csdn.net/article/details/102486288
- 点赞
- 收藏
- 关注作者
评论（0）