百度360必应搜狗淘宝本站头条
当前位置:网站首页 > IT知识 > 正文

详细介绍一下Redis内部是如何执行Lua脚本的?

liuian 2025-03-20 16:22 18 浏览

在之前的分享介绍中,我们知道,Redis是通过EVAL命令或者是通过EVALSHA命令来调用执行Lua脚本的,当客户端请求执行Lua脚本的时候,脚本会通过EVAL命令传递到Redis服务器中,而EVALSHA命令则是通过已经执行了脚本加载命令SCRIPT LOAD加载到Redis中的Lua脚本的SHA1哈希值来调用执行脚本。

在Redis接收到了Lua脚本之后,会将其传递到Lua虚拟机来进行脚本的加载和编译,在Redis内部主要是通过LuaJIT来执行脚本,LuaJIT是一个高效的Lua脚本即时编译器实现,并且专门是针对Lua脚本进行了优化,可以将Lua脚本编译成高度化的机器编码,这种方式可以有效的提高脚本执行的效率。

LuaJIT的工作原理

在Lua脚本解释器执行Lua脚本代码的时候,首先会将Lua脚本源码编译成为字节码文件,然后通过Lua虚拟机去逐条的解释并且执行这些代码中的字节码,而LuaJIT中执行Lua脚本的时候,也会将Lua脚本先转换成字节码,然后会对这个字节码进行进一步的优化来脚本执行的效率。

只不过与标准Lua脚本解释器不同的是LuaJIT提供的事一种即时编译的机制,也就在运行的时候会将字节码即时编译成机器码,这种编译与传统的编译型语言不同的是这种编译是在程序执行的过程中进行的,而传统的C或者C++就是在编译时就已经生成了字节码文件。通过LuaJIT的即时编译机制使得在Lua脚本在脚本执行的时候达到接近原生代码执行的速度。

在脚本执行过程中,LuaJIT技术会自动检测程序中的热路径,所谓的热路径就是指被频繁执行的代码,然后将这些热路径编译成机器码,这样程序中就会直接执行这些已经编译好的机器码,如果某些逻辑是第一次执行,那么在执行的时候也会被JIT机制编译为机器码。在LuaJIT运行的过程中会对数据类型也进行优化,避免在执行机器码的过程中每次都对数据类型进行检查。

在标准的Lua虚拟机中,会通过栈来存储中间运行结果信息,但是在LuaJIT中则是通过寄存器虚拟机来实现这种机制,其实提到寄存器很多开发者就会明白它的操作效率要比栈的操作效率要更高,这样也是通过这种寄存器模型来提高命令执行的效率,减少栈操作带来的其他系统开销。

在LuaJIT中通过使用内联缓存技术来提高内部函数调用以及查找调用的效率,当LuaJIT发现某个函数或者是方法调用频率较高的时候,那么就会对其地址进行缓存,这样这个方法在后续的调用过程中会直接进行跳转而不需要再次进行寻址查找,从而减少了方法查找和调用带来的系统开销。

既然是虚拟机那么不可或缺的就是垃圾回收机制,在LuaJIT中提供的垃圾回收机制与Lua中提供的垃圾回收机制类似,都是采用了标记清除算法,并且对垃圾的回收做了一定的优化,由于Lua脚本的调用执行效率较高,所以垃圾回收的速度效率也会比较高一点。

Lua脚本的键锁定

在之前的介绍中,我们提到过Lua脚本执行的过程中,Redis会对Lua脚本操作的键值进行加锁,这样是为了保证脚本执行的原子性,也就是说在Lua脚本执行的过程中,其他的客户端无法对操作的键值进行修改。

Redis对键值锁定的方式被称为是键级锁定,这种锁定机制通过一种被叫做分布式锁的机制来实现,确保在操作该键的时候不会被其他的客户端操作所修改。也就是说Redis中将会对所有的涉及到操作的键值进行独立管理,在脚本执行的过程中确保脚本的操作不会被其他的命令操作所打断。

从底层实现来讲其实还是基于了Redis的事务队列实现,在脚本执行的过程中,是按照顺序对脚本命令进行执行,如下所示。

int evalGenericCommand(redisClient *c, int issha) {
    // 获取 Lua 脚本中的键
    unsigned long numkeys = 0;
    robj **keys = luaScriptKeys(c->argv[1], c->argc, &numkeys);  // 获取涉及的键

    // 锁定涉及的键
    lockKeysForScript(keys, numkeys);
    
    // 执行 Lua 脚本
    executeLuaScript(c, keys, numkeys);
    
    // 解锁所有键
    unlockKeys(keys, numkeys);
}

当脚本执行完成之后,也会主动去释放所有被锁定的键值。

Redis中如何执行Lua脚本

在Redis中通过EVAL命令来调用Lua脚本,而在编写Lua脚本的时候,涉及到了redis.call()redis.pcall()这两个函数,这两个函数在脚本执行的过程中都会通过Redis提供的处理机制来与Redis数据库底层进行交互,而我们知道Redis底层命令执行是通过一个统一的命令调度框架来实现,也就是说redis.call()redis.pcall()这两个函数也是基于这个Redis命令调度框架来执行。

redis.call()函数的底层实现

在Redis中解析到了redis.call()函数的时候,这条命令就会被解析成Redis支持的RESP格式,也就是说函数调用会被解析为一条Redis的执行命令,然后进入到到Redis的命令调度机制中,通过命令表server.command_table来查找到对应的命令执行函数进行调用,例如常见的SET命令会被映射到setCommand 函数中。

一旦找到了命令处理函数,那么就会执行该函数进行实际的数据处理操作,并修改Redis内部的数据处理状态,处理完成之后返回对应的命令执行结果。

/* 用于执行 Redis 命令 */
int redisCommand(lua_State *lua) {
    int argc = lua_gettop(lua);   // 获取参数的数量
    // 获取命令名称
    const char *command = lua_tostring(lua, 1);
    // 创建一个 Redis 命令的参数列表
    robj **argv = (robj **) zmalloc(sizeof(robj*) * argc);
    for (int i = 0; i < argc; i++) {
        argv[i] = luaToObject(lua, i + 2);  // 从 Lua 栈中获取参数并转换成 Redis 对象
    }
    
    // 执行 Redis 命令
    int retval = call(command, argc, argv);
    zfree(argv);  // 释放参数列表
    return retval;
}

如果在处理过程中,发现了异常redis.call()函数也会抛出异常并且终止Lua脚本的执行,并且会将错误信息返回到客户端。

由于Redis的命令是在Redis主线程中执行完成的,所以在发现错误之后会立即返回并且剩余的命令将不会被执行,这个机制与Redis事务提供的机制有所不同。

redis.pcall()函数的底层实现

这个函数的底层实现与redis.call()的底层实现机制类似,唯一不同的是redis.pcall() 命令提供了一个内置的错误捕获机制,在命令执行的过程中通过这个错误捕获机制来保护Lua脚本执行的准确性,这种机制会捕获在执行过程中发生的任何错误并且会返回一个包含了所有错误的信息表,并不会直接抛出异常。

/* 用于执行 Redis 命令,并捕获错误 */
int redisPcall(lua_State *lua) {
    int argc = lua_gettop(lua);
    const char *command = lua_tostring(lua, 1);
    robj **argv = (robj **) zmalloc(sizeof(robj*) * argc);
    for (int i = 0; i < argc; i++) {
        argv[i] = luaToObject(lua, i + 2);
    }

    // 使用 pcall 保护性调用 Redis 命令
    int retval = lua_pcall(lua, command, argc, argv);
    zfree(argv);
    return retval;
}

也就是说,脚本执行过程中如果某些脚本执行失败了,redis.pcall() 会封装一个Lua的错误异常表,后续的的命令还会继续执行,并不会受到错误异常处理的影响,当脚本执行完成之后,会返回给最终脚本执行之后的一个错误异常表。这种机制就与Redis提供的事务机制有点类似了。

result = redis.pcall('GET', 'non_existing_key')
if result.err then
    -- 错误处理
    return "Key not found"
else
    return result
end

上面两种机制,主要的差异就体现在对于错误的处理方式上,在实际操作过程中我们可以根据实际需要的业务处理方式来选择合适的调用方式。

总结

Redis中执行Lua脚本的过程包括脚本的加载、编译、键的锁定、执行以及结果返回等过程。通过Lua脚本的调用执行,Redis实现了对多个Redis命令组合的的原子操作,并通过锁定机制确保了脚本执行期间的数据一致性和事务性。Lua脚本的原子性和高效性,使得在复杂的操作场景下,Redis 能够提供更加灵活的解决方案。

相关推荐

eino v0.4.5版本深度解析:接口类型处理优化与错误机制全面升级

近日,eino框架发布了v0.4.5版本,该版本在错误处理、类型安全、流处理机制以及代理配置注释等方面进行了多项优化与修复。本次更新共包含6个提交,涉及10个文件的修改,由2位贡献者共同完成。本文将详...

SpringBoot异常处理_springboot异常注解

在SpringBoot中,异常处理是构建健壮、可维护Web应用的关键部分。良好的异常处理机制可以统一返回格式、提升用户体验、便于调试和监控。以下是SpringBoot中处理异常的完整指...

Jenkins运维之路(Jenkins流水线改造Day02-1-容器项目)

这回对线上容器服务器的流水线进行了一定的改造来满足目前线上的需求,还是会将所有的自动化脚本都放置到代码库中统一管理,我感觉一章不一定写的完,所以先给标题加了个-1,话不多说开干1.本次流水线的流程设计...

告别宕机!零基础搭建服务器监控告警系统!小白也能学会!

前言本文将带你从零开始,一步步搭建一个完整的服务器指标监控与邮件告警系统,使用的技术栈均为业界主流、稳定可靠的开源工具:Prometheus:云原生时代的监控王者,擅长指标采集与告警规则定义Node_...

httprunner实战接口测试笔记,拿走不谢

每天进步一点点,关注我们哦,每天分享测试技术文章本文章出自【码同学软件测试】码同学公众号:自动化软件测试码同学抖音号:小码哥聊软件测试01开始安装跟创建项目pipinstallhttprunne...

基于JMeter的性能压测平台实现_jmeter压测方案

这篇文章已经是两年前写的,短短两年时间,JMeter开源应用技术的发展已经是翻天覆地,最初由github开源项目zyanycall/stressTestPlatform形成的这款测试工具也开始慢...

12K+ Star!新一代的开源持续测试工具!

大家好,我是Java陈序员。在企业软件研发的持续交付流程中,测试环节往往是影响效率的关键瓶颈,用例管理混乱、接口调试复杂、团队协作不畅、与DevOps流程脱节等问题都能影响软件交付。今天,给大家...

Spring Boot3 中分库分表之后如何合并查询

在当今互联网应用飞速发展的时代,数据量呈爆发式增长。对于互联网软件开发人员而言,如何高效管理和查询海量数据成为了一项关键挑战。分库分表技术应运而生,它能有效缓解单库单表数据量过大带来的性能瓶颈。而在...

离线在docker镜像方式部署ragflow0.17.2

经常项目上会出现不能连外网的情况,要怎么使用ragflow镜像部署呢,这里提供详细的步骤。1、下载基础镜像根据docker-compose-base.yml及docker-compose.yml中的i...

看,教你手写一个最简单的SpringBoot Starter

何为Starter?想必大家都使用过SpringBoot,在SpringBoot项目中,使用最多的无非就是各种各样的Starter了。那何为Starter呢?你可以理解为一个可拔插式...

《群星stellaris》军事基地跳出怎么办?解决方法一览

《群星stellaris》军事基地跳出情况有些小伙伴出现过这种情况,究竟该怎么解决呢?玩家“gmjdadk”分享的自己的解决方法,看看能不能解决。我用英文原版、德语、法语和俄语四个版本对比了一下,结果...

数据开发工具dbt手拉手教程-03.定义数据源模型

本章节介绍在dbt项目中,如何定义数据源模型。定义并引入数据源通过Extract和Load方式加载到仓库中的数据,可以使用dbt中的sources组件进行定义和描述。通过在dbt中将这些数据集(表)声...

docker compose 常用命令手册_docker-compose init

以下是DockerCompose常用命令手册,按生命周期管理、服务运维、构建配置、扩缩容、调试工具分类,附带参数解析、示例和关键说明,覆盖多容器编排核心场景:一、生命周期管理(核心命令...

RagFlow与DeepSeek R1本地知识库搭建详细步骤及代码实现

一、环境准备硬件要求独立显卡(建议NVIDIAGPU,8GB显存以上)内存16GB以上,推荐32GB(处理大规模文档时更高效)SSD硬盘(加速文档解析与检索)软件安装bash#必装组件Docker...

Docker Compose 配置更新指南_docker-compose配置

高效管理容器配置变更的最佳实践方法重启范围保留数据卷适用场景docker-composeup-d变更的服务常规配置更新--force-recreate指定/所有服务强制重建down→up流程...