redis的watch命令没有ABA的问题

结论

redis使用watch的时候没有ABA的问题

实验如下图

两个客户端，第一个客户端watch一个key后，第二个客户端修改这个key再恢复到原状，然后第一个客户端执行事务时发现事务失败

原理说明

在每个代表数据库的 redis.h/redisDb 结构类型中， 都保存了一个 watched_keys 字典， 字典的键是这个数据库被监视的键， 而字典的值则是一个链表， 链表中保存了所有监视这个键的客户端。

比如说，以下字典就展示了一个 watched_keys 字典的例子：

其中， 键 key1 正在被 client2 、 client5 和 client1 三个客户端监视， 其他一些键也分别被其他别的客户端监视着。

　WATCH 命令的作用， 就是将当前客户端和要监视的键在 watched_keys 中进行关联。

　举个例子， 如果当前客户端为 client10086 ， 那么当客户端执行 WATCH key1 key2 时， 前面展示的 watched_keys 将被修改成这个样子

通过 watched_keys 字典， 如果程序想检查某个键是否被监视， 那么它只要检查字典中是否存在这个键即可； 如果程序要获取监视某个键的所有客户端， 那么只要取出键的值（一个链表）， 然后对链表进行遍历即可

WATCH 的触发

　在任何对数据库键空间（key space）进行修改的命令成功执行之后 （比如 FLUSHDB 、 SET 、 DEL 、 LPUSH 、 SADD 、 ZREM ，诸如此类）， multi.c/touchWatchedKey 函数都会被调用 —— 它检查数据库的 watched_keys 字典， 看是否有客户端在监视已经被命令修改的键， 如果有的话， 程序将所有监视这个/这些被修改键的客户端的 REDIS_DIRTY_CAS 选项打开：

当客户端发送 EXEC 命令、触发事务执行时， 服务器会对客户端的状态进行检查：

　如果客户端的 REDIS_DIRTY_CAS 选项已经被打开，那么说明被客户端监视的键至少有一个已经被修改了，事务的安全性已经被破坏。服务器会放弃执行这个事务，直接向客户端返回空回复，表示事务执行失败。
　如果 REDIS_DIRTY_CAS 选项没有被打开，那么说明所有监视键都安全，服务器正式执行事务。
可以用一段伪代码来表示这个检查：

def check_safety_before_execute_trasaction():

    if client.state & REDIS_DIRTY_CAS:
        # 安全性已破坏，清除事务状态
        clear_transaction_state(client)
        # 清空事务队列
        clear_transaction_queue(client)
        # 返回空回复给客户端
        send_empty_reply(client)
    else:
        # 安全性完好，执行事务
        execute_transaction()

举个例子，假设数据库的 watched_keys 字典如下图所示：

如果某个客户端对 key1 进行了修改（比如执行 DEL key1 ）， 那么所有监视 key1 的客户端， 包括 client2 、 client5 和 client1 的 REDIS_DIRTY_CAS 选项都会被打开， 当客户端 client2 、 client5 和 client1 执行 EXEC 的时候， 它们的事务都会以失败告终。

　最后，当一个客户端结束它的事务时，无论事务是成功执行，还是失败， watched_keys 字典中和这个客户端相关的资料都会被清除

代码追踪

结构存储如下

watch一个key时，会把那个client加入到这个key的监控列表尾部

修改，删除，重命名，flushDB，swapDB等造成数据修改时，都算是"Touch"了一个key，若这个key是被watch的，则会修改这个key的所有监控client的标记，置为CLIENT_DIRTY_CAS，意思也很明确，就是这个客户端的所有CAS操作都“脏”了，不能再执行了

当服务器收到exec命令时，会先检测这个client是否有CLIENT_DIRTY_CAS标记，若有该标记，就直接返回，不再处理事务