Redis watch机制的分析

最新推荐文章于 2024-09-09 10:52:25 发布
最新推荐文章于 2024-09-09 10:52:25 发布
阅读量991 收藏 3
点赞数
文章标签： 数据库 java 数据结构与算法
原文链接：https://juejin.im/post/5b5d32f5f265da0f8d366f28
版权

Redis watch机制的分析

我们常用redis的watch和multi来处理一些涉及并发的操作，redis的watch+multi实际是一种乐观锁，今天我们来分析一下它的实现机制。

常用的代码段

$key = 'xxxx';
$redis->watch($key);
$redis->multi();
// 更新了key
$redis->set($key);
$flag = $redis->exec();

// 如果事务执行失败返回false
if ($flag === false) {
    
} else {
    
}
复制代码

流程图

当客户端A和客户端B同时执行这段代码时候，因为事务的执行是串行的，假设A客户端先于B执行，那么当A执行完成时，会将客户端A从watch了这个key的列表中删除，并且将列表中的所有客户端都设置为CLIENT_DIRTY_CAS，之后当B执行的时候，事务发现B的状态是CLIENT_DIRTY_CAS，便终止事务并返回失败。

存储

  1. redis 用了哈希表+链表存储watch了key的客户端：

哈希表key为redis的key，哈希表的value为客户端组成的链表

定位key的复杂度O(1)，查找和处理客户端的复杂度为O(n)

Key1 => (client1->client2->client3...)

Key2 => (client1->client2->client3...)

  1. 每个客户端也维护一个链表用来存储已经watch的key

相关源码

涉及文件

multi.h

multi.c

db.c

t_string.c

watch

/* watch命令 */
void watchCommand(client *c) {
    int j;

    if (c->flags & CLIENT_MULTI) {
        addReplyError(c,"WATCH inside MULTI is not allowed");
        return;
    }
    for (j = 1; j < c->argc; j++)
        watchForKey(c,c->argv[j]);
    addReply(c,shared.ok);
}

typedef struct watchedKey {
    robj *key;
    redisDb *db;
} watchedKey;

/* watch一个key */
void watchForKey(client *c, robj *key) {
    list *clients = NULL;
    listIter li;
    listNode *ln;
    watchedKey *wk;

    /* 检查key是否已经watch 如果已经watch 直接返回 */
    // 创建一个迭代器
    listRewind(c->watched_keys,&li);
    // 遍历客户端已经watch的key
    while((ln = listNext(&li))) {
        wk = listNodeValue(ln);
        // 当发现已经存在次key，直接返回
        if (wk->db == c->db && equalStringObjects(key,wk->key))
            return; /* Key already watched */
    }
    /* 没有被watch，继续一下处理 */
    // 获取hash表中当前key的客户端链表
    clients = dictFetchValue(c->db->watched_keys,key);
    // 如果不存在，则创建一个链表用于存储
    if (!clients) {
        clients = listCreate();
        dictAdd(c->db->watched_keys,key,clients);
        incrRefCount(key);
    }
    // 添加当前客户端到链表末尾
    listAddNodeTail(clients,c);
    /* 维护客户端中的watch_keys 链表 */
    wk = zmalloc(sizeof(*wk));
    wk->key = key;
    wk->db = c->db;
    incrRefCount(key);
    listAddNodeTail(c->watched_keys,wk);
}
复制代码

multi

/* multi 命令 */
void multiCommand(client *c) {
    // 如果已经初始化了客户端状态，即已经执行了multi 则返回
    if (c->flags & CLIENT_MULTI) {
        addReplyError(c,"MULTI calls can not be nested");
        return;
    }
    // 初始化客户端状态为CLIENT_MULTI
    c->flags |= CLIENT_MULTI;
    addReply(c,shared.ok);
}

/* 初始化客户端状态 清空事务日志队列 */
void initClientMultiState(client *c) {
    c->mstate.commands = NULL;
    c->mstate.count = 0;
}
复制代码

exec

/* exec 命令 */
void execCommand(client *c) {
    int j;
    robj **orig_argv;
    int orig_argc;
    struct redisCommand *orig_cmd;
    int must_propagate = 0; /* Need to propagate MULTI/EXEC to AOF / slaves? */
    int was_master = server.masterhost == NULL;
	
    // 未执行multi，则返回
    if (!(c->flags & CLIENT_MULTI)) {
        addReplyError(c,"EXEC without MULTI");
        return;
    }
	
    /*
     * 关键
     * 处理客户端状态 以下两种状态会直接终止事务，不会执行事务队列中的命令
     * 1. CLIENT_DIRTY_CAS => 当因为watch的key被touch了
     * 2. CLIENT_DIRTY_EXEC => 当客户端入队了不存在的命令
     */
    
    /* Check if we need to abort the EXEC because:
     * 1) Some WATCHed key was touched.
     * 2) There was a previous error while queueing commands.
     * A failed EXEC in the first case returns a multi bulk nil object
     * (technically it is not an error but a special behavior), while
     * in the second an EXECABORT error is returned. */
    if (c->flags & (CLIENT_DIRTY_CAS|CLIENT_DIRTY_EXEC)) {
        addReply(c, c->flags & CLIENT_DIRTY_EXEC ? shared.execaborterr :
                                                  shared.nullmultibulk);
        // 
        discardTransaction(c);
        goto handle_monitor;
    }

    /* 执行队列中的命令 */
    // 清空当前客户端中存储的watch了的key，和hash表中客户端node
    unwatchAllKeys(c); /* Unwatch ASAP otherwise we'll waste CPU cycles */
    orig_argv = c->argv;
    orig_argc = c->argc;
    orig_cmd = c->cmd;
    addReplyMultiBulkLen(c,c->mstate.count);
    // 执行队列中的命令
    for (j = 0; j < c->mstate.count; j++) {
        c->argc = c->mstate.commands[j].argc;
        c->argv = c->mstate.commands[j].argv;
        c->cmd = c->mstate.commands[j].cmd;

        /* Propagate a MULTI request once we encounter the first command which
         * is not readonly nor an administrative one.
         * This way we'll deliver the MULTI/..../EXEC block as a whole and
         * both the AOF and the replication link will have the same consistency
         * and atomicity guarantees. */
        if (!must_propagate && !(c->cmd->flags & (CMD_READONLY|CMD_ADMIN))) {
            execCommandPropagateMulti(c);
            must_propagate = 1;
        }
		// 这里会call相关的命令
        // 如果是涉及到修改相关的命令，不管有没有更改值，都会将hash表中watch了key的客户端的状态置为CLIENT_DIRTY_CAS
        call(c,CMD_CALL_FULL);

        /* Commands may alter argc/argv, restore mstate. */
        c->mstate.commands[j].argc = c->argc;
        c->mstate.commands[j].argv = c->argv;
        c->mstate.commands[j].cmd = c->cmd;
    }
    c->argv = orig_argv;
    c->argc = orig_argc;
    c->cmd = orig_cmd;
    discardTransaction(c);

    /* Make sure the EXEC command will be propagated as well if MULTI
     * was already propagated. */
    if (must_propagate) {
        int is_master = server.masterhost == NULL;
        server.dirty++;
        /* If inside the MULTI/EXEC block this instance was suddenly
         * switched from master to slave (using the SLAVEOF command), the
         * initial MULTI was propagated into the replication backlog, but the
         * rest was not. We need to make sure to at least terminate the
         * backlog with the final EXEC. */
        if (server.repl_backlog && was_master && !is_master) {
            char *execcmd = "*1\r\n$4\r\nEXEC\r\n";
            feedReplicationBacklog(execcmd,strlen(execcmd));
        }
    }

handle_monitor:
    /* Send EXEC to clients waiting data from MONITOR. We do it here
     * since the natural order of commands execution is actually:
     * MUTLI, EXEC, ... commands inside transaction ...
     * Instead EXEC is flagged as CMD_SKIP_MONITOR in the command
     * table, and we do it here with correct ordering. */
    if (listLength(server.monitors) && !server.loading)
        replicationFeedMonitors(c,server.monitors,c->db->id,c->argv,c->argc);
}

/* 清空当前事务数据 */
void discardTransaction(client *c) {
    freeClientMultiState(c);
    initClientMultiState(c);
    c->flags &= ~(CLIENT_MULTI|CLIENT_DIRTY_CAS|CLIENT_DIRTY_EXEC);
    unwatchAllKeys(c);
}

/* Unwatch all the keys watched by this client. To clean the EXEC dirty
 * flag is up to the caller. */
void unwatchAllKeys(client *c) {
    listIter li;
    listNode *ln;

    if (listLength(c->watched_keys) == 0) return;
    listRewind(c->watched_keys,&li);
    while((ln = listNext(&li))) {
        list *clients;
        watchedKey *wk;

        /* Lookup the watched key -> clients list and remove the client
         * from the list */
        wk = listNodeValue(ln);
        clients = dictFetchValue(wk->db->watched_keys, wk->key);
        serverAssertWithInfo(c,NULL,clients != NULL);
        listDelNode(clients,listSearchKey(clients,c));
        /* Kill the entry at all if this was the only client */
        if (listLength(clients) == 0)
            dictDelete(wk->db->watched_keys, wk->key);
        /* Remove this watched key from the client->watched list */
        listDelNode(c->watched_keys,ln);
        decrRefCount(wk->key);
        zfree(wk);
    }
}
复制代码

set,hset 以set命令为?

void setGenericCommand(client *c, int flags, robj *key, robj *val, robj *expire, int unit, robj *ok_reply, robj *abort_reply) {
    long long milliseconds = 0; /* initialized to avoid any harmness warning */

    if (expire) {
        if (getLongLongFromObjectOrReply(c, expire, &milliseconds, NULL) != C_OK)
            return;
        if (milliseconds <= 0) {
            addReplyErrorFormat(c,"invalid expire time in %s",c->cmd->name);
            return;
        }
        if (unit == UNIT_SECONDS) milliseconds *= 1000;
    }

    if ((flags & OBJ_SET_NX && lookupKeyWrite(c->db,key) != NULL) ||
        (flags & OBJ_SET_XX && lookupKeyWrite(c->db,key) == NULL))
    {
        addReply(c, abort_reply ? abort_reply : shared.nullbulk);
        return;
    }
    // 看这里? 设置string的值
    setKey(c->db,key,val);
    server.dirty++;
    if (expire) setExpire(c,c->db,key,mstime()+milliseconds);
    notifyKeyspaceEvent(NOTIFY_STRING,"set",key,c->db->id);
    if (expire) notifyKeyspaceEvent(NOTIFY_GENERIC,
        "expire",key,c->db->id);
    addReply(c, ok_reply ? ok_reply : shared.ok);
}

/* SET key value [NX] [XX] [EX <seconds>] [PX <milliseconds>] */
void setCommand(client *c) {
    int j;
    robj *expire = NULL;
    int unit = UNIT_SECONDS;
    int flags = OBJ_SET_NO_FLAGS;

    for (j = 3; j < c->argc; j++) {
        char *a = c->argv[j]->ptr;
        robj *next = (j == c->argc-1) ? NULL : c->argv[j+1];

        if ((a[0] == 'n' || a[0] == 'N') &&
            (a[1] == 'x' || a[1] == 'X') && a[2] == '\0' &&
            !(flags & OBJ_SET_XX))
        {
            flags |= OBJ_SET_NX;
        } else if ((a[0] == 'x' || a[0] == 'X') &&
                   (a[1] == 'x' || a[1] == 'X') && a[2] == '\0' &&
                   !(flags & OBJ_SET_NX))
        {
            flags |= OBJ_SET_XX;
        } else if ((a[0] == 'e' || a[0] == 'E') &&
                   (a[1] == 'x' || a[1] == 'X') && a[2] == '\0' &&
                   !(flags & OBJ_SET_PX) && next)
        {
            flags |= OBJ_SET_EX;
            unit = UNIT_SECONDS;
            expire = next;
            j++;
        } else if ((a[0] == 'p' || a[0] == 'P') &&
                   (a[1] == 'x' || a[1] == 'X') && a[2] == '\0' &&
                   !(flags & OBJ_SET_EX) && next)
        {
            flags |= OBJ_SET_PX;
            unit = UNIT_MILLISECONDS;
            expire = next;
            j++;
        } else {
            addReply(c,shared.syntaxerr);
            return;
        }
    }

    c->argv[2] = tryObjectEncoding(c->argv[2]);
    setGenericCommand(c,flags,c->argv[1],c->argv[2],expire,unit,NULL,NULL);
}

/* High level Set operation. This function can be used in order to set
 * a key, whatever it was existing or not, to a new object.
 *
 * 1) The ref count of the value object is incremented.
 * 2) clients WATCHing for the destination key notified.
 * 3) The expire time of the key is reset (the key is made persistent).
 *
 * All the new keys in the database should be craeted via this interface. */
void setKey(redisDb *db, robj *key, robj *val) {
    if (lookupKeyWrite(db,key) == NULL) {
        dbAdd(db,key,val);
    } else {
        dbOverwrite(db,key,val);
    }
    incrRefCount(val);
    removeExpire(db,key);
    // 看这里? 标记hash表中所有已经watch这个key的所有客户端状态为CLIENT_DIRTY_CAS
    // 如果我原先的值为1，这里set为1，也会执行这个方法。所以说和值变没变没关系。
    signalModifiedKey(db,key);
}

void signalModifiedKey(redisDb *db, robj *key) {
    touchWatchedKey(db,key);
}

/* 更新hash表中相应客户端的状态为CLIENT_DIRTY_CAS */
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 */
    listRewind(clients,&li);
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);

        c->flags |= CLIENT_DIRTY_CAS;
    }
}
复制代码
weixin_34198762
关注
Redis Watch机制实现分布式乐观锁
qq_36305027的博客
08-31 501
关于ABA的介绍在这里就不做说明了，简单来说就是一个线程将A修改成B，接着又将B修改成A，那样对原线程来讲A这个值就没有变，这就是ABA的问题，关于如何避免这个问题上面采用的版本号递增是一个方案。​ Redis使用Watch机制实现乐观锁是基于CAS（Compare And Swap）思想（比较并替换），是不具有互斥性，不会产生锁等待而消耗资源，但是需要反复的重试，但也是因为重试的机制，能比较快的响应。命令所监控的键值对，如果没有发生变化，那么它会执行事务队列中的命令，提交事务；...
redis的淘汰机制分析
qq_35267557的博客
08-22 553
Redis的Key淘汰机制分析
redis的Watch机制是什么？
Prodigal
12-07 5158
watch机制 Redis Watch 命令用于监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断 语法 redis Watch 命令基本语法如下： WATCH key [key …] 验证： 首先开启两个redis客户端，客户端1和客户端2. 1、客户端1中，先set一个值 redis 127.0.0.1:6379> se...
redis的事务和watch机制
baomingshu的博客
08-31 847
Redis 中的事务（transaction）是一个单独隔离的操作，保证两个或两个以上的命令集合按需排队并顺序执行，中间不会被任何其他操作打断。7）在 A 客户端查看 str.lp 值，A 客户端执行的事务没有提交，因为 WATCH 的 str.lp 的值已经被修改了， 所以放弃了事务。①watch 监视某个或者某几个key的值，如果有 key 的 value 值在事务 EXEC 执行之前被修改了，那么事务将被打断。①组队时出错，错误对于redis来说是已知的，事务中的所有指令都会失效。
redis的watch机制及应用
加油，努力，认真
04-21 9922
WATCH 机制原理： WATCH 机制：使用 WATCH 监视一个或多个 key , 跟踪 key 的 value 修改情况，如果有key 的 value 值在事务 EXEC 执行之前被修改了，整个事务被取消。EXEC 返回提示信息，表示 事务已经失败。 WATCH 机制使的事务 EXEC 变的有条件，事务只有在被 WATCH 的 key 没有修改的前提下才能执行。不满足条件，事务被取消。使用 WATCH 监视了一个带过期时间的键，那么即使这个键过期了，事务仍然可以正常执行. 大多数情况下，不同的客户端会
Redis事务和watch
weixin_34080951的博客
08-20 132
redis的事务 严格意义来讲,redis的事务和我们理解的传统数据库(如mysql)的事务是不一样的。 redis中的事务定义 Redis中的事务（transaction）是一组命令的集合。 事务同命令一样都是Redis的最小执行单位，一个事务中的命令要么都执行，要么都不执行。事务的原理是先将属于一个事务的命令发送给Redis，然后再让Redis依次执行这些命令。 Redis保...
Redis事务中的watch机制-从实例入手学习
BADAO_LIUMANG_QIZHI的博客
03-23 408
场景 Redis中事务的实现流程： https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/105048241 在上面学会Redis的事务的使用流程后，Redis还有一个watch机制。 Watch机制原理 使用watch监视一个或者多个key，跟踪key的value修改情况，如果有key的value值在 事务exec执行之前...
redis使用watch秒杀抢购思路.pdf
08-12
"Redis 使用 Watch 机制实现秒杀抢购思路" Redis Watch 机制 在高并发的秒杀抢购场景中，如何确保数据的一致性和安全性是非常重要的。Redis 的 Watch 机制可以很好地解决这个问题。Watch 机制是 Redis 的一种乐观...
redis中的事务操作案例分析
12-16
本文将通过案例分析，探讨Redis中的事务操作。 **一、Redis事务与MySQL事务的区别** 在MySQL中，事务支持ACID（原子性、一致性、隔离性和持久性）特性，提供了多行操作的原子性，确保数据的一致性。而Redis的事务...
深入理解Redis 事务机制及执行流程源码解析
MSSPLANET的博客
02-17 890
本篇文章将从源码角度分析整个Redis事务执行的流程，包括MULTI、EXEC、DISCARD、WATCH命令的源码实现以及相关数据结构。 本文源码版本为Redis 5.0，文中涉及到的源码均可在server.h、server.c以及multi.c三个文件中找到。 源码阅读不易，如出现纰漏或理解错误还望指正。
Redis实现分析
11-12
Redis的事务是通过MULTI、EXEC、WATCH等命令实现的。在MULTI命令之后，所有命令都会排队等待，直到EXEC命令来一次性执行这些命令。 #### RDB RDB是Redis的一种持久化方式，它通过创建数据的快照来保存某个时间点上...
Redis事务涉及的watch、multi等命令详解
12-16
Redis Watch 命令 作用：  用于监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。  用法： redis 127.0.0.1:6379> WATCH key1 key2 OK Redis Unwatch 命令 作用：  用于取消 WATCH 命令对所有 key 的监视。  用法： redis 127.0.0.1:6379> UNWATCH OK Redis Multi 命令 作用：  用于标记一个事务块的开始。事务块内的多条命令会按照先后顺序被放进一个队列当中，最后由 EXEC 命令原子性(atomic)地执行。
watchdog,监控 redis 节点的状态
06-11
watchdog：监控 redis 节点的状态，并在主节点故障时启用从节点——这是一个高可用组件
redis事务中的WATCH
xiaomin1991222的专栏
03-10 1307
在Redis的事务中，WATCH命令可用于提供CAS(check-and-set)功能。假设我们通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Null multi-bulk应答以通知调用者事务执行失败。例如，我们再次假设Redis中并未提供incr命令来完成键值的原子性递增，如果要实现该功能，我们只能自
Redis的watch机制详解
最新发布
jkzyx123的博客
09-09 1162
Redis 的WATCH机制为 Redis 提供了一种高效的乐观锁解决方案，允许客户端通过监视键的变化来控制并发事务的安全执行。它适用于高并发场景下的事务操作，同时能保持 Redis 的高性能特性。不过，在高冲突环境下，需要结合业务逻辑进行适当的重试或其他并发控制措施。
【Redis】聊一下Redis事务以及watch机制
日拱一卒，不期速成！
05-24 1221
聊一下Redis事务以及watch机制
redis watch
pzqingchong的专栏
10-31 352
watch a  set a 7 multi set a 8 exec 执行失败返回nil 说明在watch后 无论是自身链接还是其他链接 修改 a, 当前下一次 multi set a exec都会失败 exec 会观察当前链接最近一次 watch的值和当前值 是否 有变化 如果有变化 则执行失败
Redis watch命令 详解，监控事务提交
kevink的博客
07-16 418
欢迎大家访问我的博客www.kevink.club, 定时更新php, swoole, golang,redis等内容 在 Redis 中使用 watch 命令可以决定事务是执行还是回滚。一般而言，可以在 multi 命令之前使用 watch 命令监控某些键值对，然后使用 multi 命令开启事务，执行各类对数据结构进行操作的命令，这个时候这些命令就会进入队列。 当 Redis 使用 exec 命令执行事务的时候，它首先会去比对被 watch 命令所监控的键值对，如果没有发生变化，那么它会执行事务队列.
redis - redis的事务-multi-exec-watch的原理
我的博客
10-14 963
世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。 关于redis的事务是通过multi,exec,watch三个命令实现的。 具体过程如下 1. 执行 watch key 监控事务中要操作的字段 2. 执行 multi 开启事务 3. 写入具体的业务操作 4. 执行 exec 并返回执行结果 接下来解析原理 首先 watch 监控 key 所起的作用实际上是一个乐观锁，它所监控的是在事务期间有没有其他客户端对所监控的值进行修改，通过REDIS_DIRTY_CAS作.
Redis 7.4.0源码分析与特性总结
5. **事务**：Redis通过MULTI、EXEC、WATCH等命令实现事务功能。 6. **发布订阅**：支持消息的发布和订阅模式，可以构建简单的消息系统。 7. **Lua脚本支持**：支持通过Lua脚本在服务器端执行复杂的操作。 8. **安全...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值