百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术教程 > 正文

Redis原理:multi&exec命令(redis nio原理)

mhr18 2025-03-29 19:52 31 浏览 0 评论

在Redis中,MULTI和EXEC命令提供了一种机制来确保一系列命令以原子性的方式被执行。这意味着一旦这些命令被组合在一起并发送到服务器端,它们将作为一个整体被处理:要么全部成功执行,要么完全不执行。这一特性对于需要保证数据一致性的应用场景非常有用。
具体来说,当你向Redis客户端发送MULTI命令时,标志着开始一个事务块。从这时起,直到发出EXEC为止,所有发往该Redis连接的命令都不会立即执行,而是被暂时缓存起来。只有当EXEC命令被调用后,之前缓存的所有命令才会按照接收顺序一次性地在服务器端执行,并且整个过程是不可中断的。如果在这批命令执行过程中出现了错误(例如某个命令语法有误),那么除了导致错误的那个命令之外,其他命令仍然会被正常执行。
示例如下:

jedis.watch(key); // 在下一节中解析
// 开启批量执行
jedis.multi();
try{
    jedis.set(key,value);
    jedis.expire(expire,ttl);
    // 服务端开始执行
    jedis.exec();
catch(Exeception e) {
    // 放弃
    jedis.discard();
}

源码分析

multi命令

当我们调用multi命令时,会来到mutilCommand方法(multi.c)。

void multiCommand(client *c) {
    if (c->flags & CLIENT_MULTI) {
        addReplyError(c,"MULTI calls can not be nested");
        return;
    }
    // 给当前的客户端添加一个CLIENT_MULTI的标识
    c->flags |= CLIENT_MULTI;

    addReply(c,shared.ok);
}

该命令只是给当前客户端对象添加一个CLIENT_MULTI就直接返回了。

其他命令

而后,当我们调用set 和 expire 命令时,会经过以下的判断(server.c中方法processCommand):

// 如果连接的客户端是已经调用了multi命令
/* Exec the command */
if (c->flags & CLIENT_MULTI &&
    c->cmd->proc != execCommand &&
    c->cmd->proc != discardCommand &&
    c->cmd->proc != multiCommand &&
    c->cmd->proc != watchCommand &&
    c->cmd->proc != quitCommand &&
    c->cmd->proc != resetCommand)
{
    // 将命令添加到队列
    queueMultiCommand(c);
    addReply(c, shared.queued);
}

会判断当前客户端是否有CLIENT_MULTI,并且不是相关的命令,则会调用queueMultiCommand方法将命令加入队列。

void queueMultiCommand(client *c) {
    multiCmd *mc;

    /* No sense to waste memory if the transaction is already aborted.
     * this is useful in case client sends these in a pipeline, or doesn't
     * bother to read previous responses and didn't notice the multi was already
     * aborted. */
    // 如果标识中有CLIENT_DIRTY_CAS,则不处理,说明watch的key已经被修改
    // 在下一节中说明
    if (c->flags & (CLIENT_DIRTY_CAS|CLIENT_DIRTY_EXEC))
        return;
    // 申请命令缓存
    // 进行扩容
    c->mstate.commands = zrealloc(c->mstate.commands,
            sizeof(multiCmd)*(c->mstate.count+1));
    // 获取当前的最后一个对象
    // 进行缓存redis命令&参数
    mc = c->mstate.commands+c->mstate.count;
    mc->cmd = c->cmd;
    mc->argc = c->argc;
    mc->argv = c->argv;
    mc->argv_len = c->argv_len;

    c->mstate.count++;
    c->mstate.cmd_flags |= c->cmd->flags;
    c->mstate.cmd_inv_flags |= ~c->cmd->flags;
    c->mstate.argv_len_sums += c->argv_len_sum + sizeof(robj*)*c->argc;

    /* Reset the client's args since we copied them into the mstate and shouldn't
     * reference them from c anymore. */
    c->argv = NULL;
    c->argc = 0;
    c->argv_len_sum = 0;
    c->argv_len = 0;
}

exec 命令

void execCommand(client *c) {
    int j;
    robj **orig_argv;
    int orig_argc, orig_argv_len;
    struct redisCommand *orig_cmd;
    // 如果没有搭配multi一起使用,报错
    if (!(c->flags & CLIENT_MULTI)) {
        addReplyError(c,"EXEC without MULTI");
        return;
    }

    // .. 省略部分代码
    // 标识正在exec命令中
    server.in_exec = 1;

    orig_argv = c->argv;
    orig_argv_len = c->argv_len;
    orig_argc = c->argc;
    orig_cmd = c->cmd;
    addReplyArrayLen(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->argv_len = c->mstate.commands[j].argv_len;
        c->cmd = c->realcmd = c->mstate.commands[j].cmd;

        /* ACL permissions are also checked at the time of execution in case
         * they were changed after the commands were queued. */
        int acl_errpos;
        int acl_retval = ACLCheckAllPerm(c,&acl_errpos);
        if (acl_retval != ACL_OK) {
            // 省略部分代码..
        } else {
            // 调用命令
            if (c->id == CLIENT_ID_AOF)
                call(c,CMD_CALL_NONE);
            else
                call(c,CMD_CALL_FULL);

            serverAssert((c->flags & CLIENT_BLOCKED) == 0);
        }

        /* 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;
    }

    // restore old DENY_BLOCKING value
    if (!(old_flags & CLIENT_DENY_BLOCKING))
        c->flags &= ~CLIENT_DENY_BLOCKING;

    c->argv = orig_argv;
    c->argv_len = orig_argv_len;
    c->argc = orig_argc;
    c->cmd = c->realcmd = orig_cmd;
    discardTransaction(c);

    server.in_exec = 0;
}

该命令就是依次遍历已经缓存的所有命令。

discard 命令

该命令放弃所有在multi之后的命令。来看下discardCommand

void discardCommand(client *c) {
    if (!(c->flags & CLIENT_MULTI)) {
        addReplyError(c,"DISCARD without MULTI");
        return;
    }
    // 放弃所有的命令
    discardTransaction(c);
    addReply(c,shared.ok);
}

discardTransaction主要处理该连接的命令缓存、重置连接状态等操作


void discardTransaction(client *c) {
    // 释放客户端的命令缓存状态
    freeClientMultiState(c);
    // 重置该连接的状态
    initClientMultiState(c);
    // 去除相关的标识
    c->flags &= ~(CLIENT_MULTI|CLIENT_DIRTY_CAS|CLIENT_DIRTY_EXEC);
    unwatchAllKeys(c);
}

freeClientMultiState释放客户端上的资源

void freeClientMultiState(client *c) {
    int j;
    // 依次释放资源
    for (j = 0; j < c->mstate.count; j++) {
        int i;
        multiCmd *mc = c->mstate.commands+j;
        //释放参数的引用
        for (i = 0; i < mc->argc; i++)
            decrRefCount(mc->argv[i]);
        zfree(mc->argv);
    }
    // 释放数组
    zfree(c->mstate.commands);
}

相关推荐

如何通过 Redis 日志排查连接超时问题

Redis是一种高性能的内存数据存储服务,但在高并发或误配置情况下,可能会出现连接超时问题。借助Redis日志,可以快速定位并解决连接超时的根本原因。以下是具体的排查和解决步骤:1.什么是R...

给你1亿的Redis key,如何高效统计?

前言有些小伙伴在工作中,可能遇到过这样的场景:老板突然要求统计Redis中所有key的数量,你随手执行了KEYS*命令,下一秒监控告警疯狂闪烁——整个Redis集群彻底卡死,线上服务大面积瘫痪。今天...

Redis分布式锁的安全性分析与实践指南

一、Redis分布式锁的核心原理Redis分布式锁通过SETNX(SetifNotExists)和EXPIRE(Expire)指令实现原子性操作,结合UUID生成唯一标识符,确保锁的互斥性和安全...

高可用Redis分布式锁:秒杀系统中的锁战

引言在分布式系统中,“程序猿的终极武器是并发控制”。当多个服务实例同时访问共享资源时,如何避免数据不一致和重复操作?答案是分布式锁。Redis凭借其高性能和原子性操作,成为实现分布式锁的首选方案。...

Redis分布式锁(redis分布式锁解决超卖)

场景描述简单模拟一个高并发库存扣减场景,商品库存加载到Redis缓存,如:127.0.0.1:6379>setproduct:stock:101200无锁状态操作从缓存中获取对应商品的库存...

Redis 分布式锁和 ZooKeeper分布式锁

Redis分布式锁和ZooKeeper(简称zk)分布式锁都是用来解决在分布式系统中多个节点之间竞争资源的问题。它们各自有不同的特点和适用场景。Redis分布式锁Redis实现分布式锁主要是...

Redis vs ZooKeeper锁:高并发下的生死对决,谁才是最终赢家?

在分布式系统中,锁是控制资源访问的重要机制。Redis和ZooKeeper作为两种主流的分布式锁实现方案,各有优劣。本文将从原理、性能、代码实现三个维度进行硬核对比,助你做出最佳技术选型。一、原理对比...

说说Redis的大key(redis key大小限制)

一句话总结Redis大key指存储超大值(如字符串过大、集合元素过多)的键。主要成因包括:1.设计不合理,未拆分数据结构;2.业务需求(如缓存整页数据);3.数据持续积累未清理;4.使用不当的集合类型...

PHP Laravel框架底层机制(php框架的底层原理)

当然可以,Laravel是最受欢迎的PHP框架之一,以优雅的语法和丰富的生态而闻名。尽管开发体验非常“高端”,它的底层其实是由一系列结构清晰、职责分明的组件构成的。下面我从整体架构、核心流程、...

PHP性能全面优化-值得收藏(php优化网站性能)

PHP项目卡顿频发,老技巧失灵?隐藏漏洞竟在代码循环里。上周公司服务器突然开始卡顿,测试发现用户请求响应时间翻倍。我们先按以前学的方法做了基准测试,用AB工具压测时发现2000并发就有5%错误,换成S...

PHP+UniApp:低成本打造外卖系统横扫App+小程序+H5全平台

在餐饮行业数字化转型中,外卖系统开发常面临两大痛点:高昂的开发成本(需独立开发App、小程序、H5)和多端维护的复杂性。PHP+UniApp的组合通过技术复用与跨平台能力,为中小商家和开发者提供了“降...

从需求到上线:PHP+Uniapp校园圈子系统源码的架构设计与性能优化

一、需求分析与架构设计1.核心功能需求用户体系:支持手机号/微信登录、多角色权限(学生、教师、管理员)。圈子管理:支持创建/加入兴趣圈子(如学术、电竞)、标签分类、动态发布与审核。实时互动:点赞、评...

PHP 8.0性能翻3倍?四年亲测:这些项目升了哭晕!

2020年那个感恩节,当PHP8.0带着“性能翻倍”的豪言横空出世时,无数程序员连夜备份代码准备升级。四年过去了,那些宣称“性能提升3倍”的项目,真的跑出火箭速度了吗?还记得当时铺天盖地的宣传吗?“...

我把 Mac mini 托管到机房了:一套打败云服务器的终极方案

本内容来源于@什么值得买APP,观点仅代表作者本人|作者:薯仔不爱吃薯仔我把我积灰的Macmini托管到机房了,有图有真相。虽然画质又渣又昏暗,但是!这就是实锤。作为开发者,谁不想拥有个自己的服...

从phpstudy到Docker:我用一个下午让开发效率翻倍的实战指南

一、为什么放弃phpstudy?上周三下午,我花了3小时将本地开发环境从phpstudy迁移到Docker,没想到第二天团队反馈:环境部署时间从2小时压缩到5分钟,跨设备协作bug减少70%。作为一个...

取消回复欢迎 发表评论: