《Redis源码学习笔记》事务

[url=http://diaocow.iteye.com/blog/1938032]《Redis源码学习笔记》文章列表[/url]

Redis中的事务，提供了一种“[b]将多个命令打包并且一次执行[/b]”的方式；

当用户输入MULTI命令时，就打开了客户端REDIS_MULTI选项，客户端从“非事务状态”切换到“事务状态”

[img]http://dl2.iteye.com/upload/attachment/0088/9442/18cca8ec-48c5-3156-8675-b0c285d6895e.png[/img]

之后客户端执行的所有命令都不会被Redis立即执行，而是放到客户端的“命令队列”里去（服务器返回QUEUED字样，表示命令已经入队），当客户端发出EXEC命令（表示客户端需要执行事务），这时候Redis从客户端的“命令队列”里依次取出命令执行，eg:

redis 127.0.0.1:6379> multi  # 客户端进入事务状态
OK
redis 127.0.0.1:6379> set name diaocow	
QUEUED					     # 命令已经入队
redis 127.0.0.1:6379> set age  25
QUEUED
redis 127.0.0.1:6379> get name
QUEUED
redis 127.0.0.1:6379> get country
QUEUED
redis 127.0.0.1:6379> exec	# 执行事务
1) OK
2) OK
3) "diaocow"
4) (nil)

用一幅图来总结客户端的命令执行流程就是：

[img]http://dl2.iteye.com/upload/attachment/0088/9450/8836e6e2-7f3b-3f4c-a5fe-d8ceb91cb733.png[/img]

刚才例子中所对应的命令队列：
[img]http://dl2.iteye.com/upload/attachment/0089/0175/cd6bad2d-54fc-34e7-8b8a-9932d335b46d.png[/img]

关于命令队列的更多细节，请看：multi.c/queueMultiCommand函数

前面说到，当客户端处于“事务”状态，所以命令都不会立即执行，而是被放到“命令队列”缓存起来，其实不准确！当客户端处于“事务”状态下，如果遇到下面几个命令，依然会立即执行：

[table]
|[b]MULTI[/b]|Redis返回错误，不允许事务嵌套|
|[b]DISCARD[/b]|丢弃当前事务（该命令只能在事务状态下使用，否则Redis返回错误）|
|[b]EXEC[/b]|执行事务， 把“命令队列”里的命令依次取出、执行，并且把执行结果放入到一个“回答队列”中，当所有命令执行完后，Redis把这个“回答队列”发送给客户端（该命令只能在事务状态下使用，否则Redis返回错误）|
|[b]WATCH[/b]|监视某些键，如果在事务执行期间，有一个“监视”的键被修改，那么事务执行失败（该命令必须在MULTI命令之前执行，否则Redis返回错误）|
[/table]
命令实现伪代码：

def multiCommand(client):
    # 不允许事务嵌套
	if client.flag & REDIS_MULTI:
		return "error"
	client.flag &= REDIS_MULTI

def discardCommand(client):
	# discard命令只能在事务状态下使用
	if not (client.flags & REDIS_MULTI):
		return "error"
	# 重置客户端的事务状态（1.释放命令队列；2.重置客户端为非事务状态；3.取消之前监视的所有键）
    resetClientMultiState(client)

def execCommand(client):
	# exec命令只能在事务状态下使用
	if not (client.flags & REDIS_MULTI):
		return "error"
	# 若某些监视的键被修改或者命令入队错误（命令不存在？参数错误？），则事务执行失败
    if client.flag & (REDIS_DIRTY_CAS|REDIS_DIRTY_EXEC):
        resetClientMultiState()
        return "error" 
    # 依次执行命令队列里的命令
    for cmd, argc, argv in client.multiState.commands:
        result.add(call(cmd, argc, argv))
    resetClientMultiState(client)
    return result

DISCARD和EXEC命令比较容易理解，下面我们重点看下WATCH命令的作用以及实现原理：

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

[img]http://dl2.iteye.com/upload/attachment/0089/0179/356551e1-b8e5-30a2-94d1-7632f2126ad9.png[/img]

[b]那这一切Redis是怎么实现的呢？[/b]

原理：RedisDb中维护了一个watched_keys字典，字典的键就是这个数据库中被“监视”的键，键值就是所有“监视”该键的客户端列表（list类型）

[img]http://dl2.iteye.com/upload/attachment/0088/9050/216aeb34-c2e6-37ee-899f-417a62bdd20b.png[/img]
[size=xx-small][i]（上图只是字典的简化画法，若严格按照字典结构画不仅较为麻烦并且不利于阐述主要思想；关于redis字典详情，请参看 [url=http://diaocow.iteye.com/blog/1935091]字典[/url]章节）[/i][/size]

当一个客户端执行watch命令时：
a. Redis会把它加入到被“监视”键的客户端列表中；
b. 同时，客户端自己也会维护一个watched_keys列表，用来保存自己所有监视的键（这个属性有什么用？是不是和RedisDb中的watched_keys属性有重叠？我们稍后会说）

当任何一个会触发键内容变更的命令执行后（譬如set），touchWatchedKey函数会被调用：它检查数据库的watched_keys字典，看该键是否正在被“监视”，如果有，那么该键所关联的所有客户端列表都将打开[b]REDIS_DIRTY_CAS[/b]选项（事务被破坏），然后当客户端执行EXEC命令时，如果发现[b]REDIS_DIRTY_CAS[/b]选项打开，则事务执行失败，整个过程用伪代码表示就是：

def touchWatchedKey(redisDb, key):
	# 获取监视该键的客户端列表
    client_list = redisDb.watched_keys.get(key)
    if client_list is None: return
    # 打开客户端的REDIS_DIRTY_CAS选项（告诉它们事务已经被破坏）
    for client in client_list:
        client.flag &= REDIS_DIRTY_CAS 

更多细节请看：multi.c/touchWatchedKey函数

刚才我们还提到过，客户端自己也维护了一个watched_keys属性——用来保存自己所监视的键，那么这个属性有什么用呢？ 我自己觉得是出于效率考虑的：

1. 防止监视相同的键，当Redis发现该客户端已经监视了某个键，则跳过该键，不做任何处理；
2. 当某个客户端（譬如A）执行完事务（或成功或失败），客户端需要清除自己之前所有监视的键，如果客户端自己没有维护自己监视了哪些键，那么Redis就必须遍历整个RedisDb.watched_keys字典，然后在每一个客户端列表中查找A并删除，效率非常低下，但若客户端自己维护了所监视键的列表，那么就不在需要遍历整个字典做清除，eg伪代码：

def unwatchAllKeys(client):
	# 若客户端没有监视任何键，则立即返回
    if len(client.watched_keys) == 0 : return
    # 遍历客户端监视的键
    for wk in client.watched_keys.copy():
    	# 取出被监视键关联的客户端列表
        client_list = redisDb.watched_keys.get(wk)
        # 删除客户端
        client_list.del(client)
        client.watched_keys.del(wk)

更多细节请看：multi.c/unwatchAllKeys函数

[b]总结：[/b]
1. 熟悉事务相关命令：multi discard exec watch
2. 了解事务执行原理
3. 了解watch命令作用以及实现原理