事务
事务的实现
执行事务
当一个处于事务状态的客户端向服务器发送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命令的时候,
服务器会拒绝执行它们提交的事务,以此来保证事务的安全性