Redis中的事务(二)

事务

事务的实现

执行事务

当一个处于事务状态的客户端向服务器发送EXEC命令时,这个EXEC命令将立即被服务器执行,服务器会遍历这个客户端的事务队列,执行队列中保存的所有命令,最后将执行命令所得的结果全部返回给客户端。

例子
  • 举个例子。对于如图所示的事务队列来说,服务器会先执行命令:
c 复制代码
SET "name" "Practical Common Lisp"

之后执行命令:

c 复制代码
GET "name"

在之后执行命令:

c 复制代码
GET "author"

最后,服务器会将执行这四个命令所得的回复返回给客户端:

c 复制代码
127.0.0.1:6379> EXEC
1) OK
2) "Practical Common Lisp"
3) OK
4) "Peter Seibel"
EXEC命令的实现原理

可以用以下伪代码来描述:

python 复制代码
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命令是一个乐观锁(optimistic locking),它可以在EXEC命令执行之前,监视任意数量的数据库键,并在EXEC命令执行时,检查被监视的键是否至少有一个已经被修改过了,如果是的话,服务器将拒绝执行事务,并向客户端返回代表事务执行失败的空回复。

例子

  • 举个例子。
c 复制代码
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> WATCH "name"
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET "name" "vinpink"
QUEUED
127.0.0.1:6379> EXEC
(nil)

如表展示了上述的事务是如何失败的。在时间T4,客户端B修改了"name"键的值,当客户端A在T5执行EXEC命令时,服务器会发现WATCH监视的键"name"已经被修改,因此服务器拒绝执行客户端A的事务,并向客户端A返回空回复

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

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

c 复制代码
typedef struct redisDb {
// ...

// 正在被WATCH命令监视的键
dict *watched_keys;

// ...
}redisDb;

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

  • 1.客户端c1和c2正在监视键"name"
  • 2.客户端c3正在监视键"age"
  • 3.客户端c2和c4正在监视键"address"
    通过执行WATCH命令,客户端可以在watched_keys字典中与被监视的键进行关联
例子
  • 举个例子。如果当前客户端为c10086,那么客户端执行以下WATCH命令之后:
c 复制代码
redis>WATCH "name" "age"
OK

上图展示的wathced_keys字典将被更新为如图所示的状态,其中用虚线包围的两个c10086节点就是由刚刚执行的WATCH命令添加到字典中的。

监视机制的触发

所有对数据库进行修改的命令,比如SET、LPUSH、SADD、ZREM、DEL、FLUSHDB等等,在执行之后都会调用multi.c/touchWatchKey

函数对watched_keys字典进行检查,查看是否有客户端正在监视刚刚被命令修改过的数据库键,如果有的话,那么touchWatchKey函数

会将监视被修改键的客户端的REDIS_DIRTY_CAS标识打开,标识客户端的事务安全性已经被破坏。touchWatchKey函数的定义额可以用以下伪代码来描述

python 复制代码
def touchWatchKey(db, key) :
# 如果键key存在于数据库的watched_keys字典中
# 那么说明至少有一个客户端在监视这个key
if key in db.watched_keys:
# 遍历所有监视键key的客户端
for client in db.watched_keys[key]:
# 打开标识
client.flags |= REDIS_DIRTY_CAS
例子
  • 举个例子。如图所示的watched_keys字典来说:
    1.如果键"name"被修改,那么c1、c2、c10086三个客户端的REDIS_DIRTY_CAS标识将被打开
    2.如果键"age"被修改,那么c3和c10086两个客户端的REDIS_DIRTY_CAS标识将被打开
    3.如果键"address"被修改,那么c2和c4两个客户端的REDIS_DIRTY_CAS标识将被打开

判断事务是否安全

当服务器接收到一个客户端发来的EXEC命令时,服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识

来决定是否执行事务:

  • 1.入股客户端的REDIS_DIRTY_CAS标识已经被打开,那么说明客户端所监视的键当中,至少有一个键已经被修改过了,在这种情况下,客户端提交的事务已经不再安全,所以服务器会拒绝执行客户端提交的事务
  • 2.如果客户端的REDIS_DIRTY_CAS标识没有被打开,那么说明客户端监视的所有键都没有被修改过(或者客户端没有监视任何键),事务仍然是安全的,服务器将执行客户端提交的这个事务。

这个判断是否执行事务的过程可以用流程图来描述

例子
  • 举个例子。对于上图的watched_keys字典来说,如果某个客户端对"name"进行了修改(比如执行SET "name" "cover"),
    那么c1、c2、c10086三个客户端的REDIS_DIRTY_CAS标识将被打开,当这三个客户端向服务器发送EXEC命令的时候,
    服务器会拒绝执行它们提交的事务,以此来保证事务的安全性
相关推荐
Yz987611 分钟前
hive的存储格式
大数据·数据库·数据仓库·hive·hadoop·数据库开发
wkj00113 分钟前
php操作redis
开发语言·redis·php
武子康15 分钟前
大数据-230 离线数仓 - ODS层的构建 Hive处理 UDF 与 SerDe 处理 与 当前总结
java·大数据·数据仓库·hive·hadoop·sql·hdfs
武子康17 分钟前
大数据-231 离线数仓 - DWS 层、ADS 层的创建 Hive 执行脚本
java·大数据·数据仓库·hive·hadoop·mysql
苏-言23 分钟前
Spring IOC实战指南:从零到一的构建过程
java·数据库·spring
Ljw...29 分钟前
索引(MySQL)
数据库·mysql·索引
界面开发小八哥30 分钟前
更高效的Java 23开发,IntelliJ IDEA助力全面升级
java·开发语言·ide·intellij-idea·开发工具
hzyyyyyyyu43 分钟前
内网安全隧道搭建-ngrok-frp-nps-sapp
服务器·网络·安全
菠萝咕噜肉i43 分钟前
超详细:Redis分布式锁
数据库·redis·分布式·缓存·分布式锁
草莓base44 分钟前
【手写一个spring】spring源码的简单实现--容器启动
java·后端·spring