利用Lua定制Redis命令的方法详解

Redis 作为一个相当成功的数据库，提供了丰富的数据类型和命令，用它们可以轻松高效地完成大量缓存操作。但总有一些特殊场景或棘手需求绕不开标准接口，这时候，自己动手定制 Redis 的数据结构和命令，就成了顺理成章的选择。

Redis 命令问题

线程安全问题

都知道 Redis 是单线程的，可它怎么会有线程安全问题？

通常理解的线程安全，指的是单进程多线程模型里，多个线程操作共享内存导致的数据冲突。而 Redis 的线程安全问题，源头不在服务器内部。

Redis 作为数据服务器，本质上是多个客户端的共享内存。多个客户端就好比同一进程下的多个线程，如果它们之间没有好的数据同步策略，就会产生类似线程安全的问题。典型场景是这样的：

• Redis 里存了一个用户状态：user5277 = idle；
• 客户端 A 读取了状态，拿到空闲；
• 客户端 B 也读取了同样的状态；
• 客户端 A 给用户安排任务，把状态设为 busy；
• 客户端 B 同样把状态设为 busy。
• 结果呢？用户被同时分配了两个任务。

根因在于：Redis 虽然是单线程、能保证命令序列化，但执行效率太高，多个客户端的命令之间没有请求同步，一样会造成顺序错乱。

解法也简单——给用户状态加锁，保证同一时间只有一个客户端能操作。但加锁又会引入锁粒度、死锁等麻烦，程序复杂度上去了，维护起来也头疼。

效率问题

Redis 作为内存数据服务器，效率高得惊人。之前看过阿里云 Redis 的压测结果：10 万写 QPS、60 万读 QPS。那它的效率问题又从哪冒出来的？

答案在网络。做 Web 的都清楚，效率优化要从网络下手。服务端搞代码优化、数据库优化，都不如一次网络连接的优化来得实在。而网络优化最有效的就是减少请求次数。执行一次内存访问大约 100ns，不同机房之间来回一次却要 500000ns，差距就是这么大。

Redis 单机内效率超高，但工业部署不可能把服务器和 Redis 放同一台机器上。一旦触碰到效率瓶颈，那一定是网络。典型场景：从 Redis 读一条数据，再用这条数据做键读另一条数据——来来回回，两次网络往返就耗进去了。

根本原因在于 Redis 的普通命令没有服务端计算能力，没法在服务器做复合命令操作。虽然 pipeline 能批量发送，但要求命令之间没有依赖关系。要想简化相互依赖的命令，就只能把数据拉到客户端，处理完再发回 Redis。

所以，要更高效、更方便地使用 Redis，就得自己“定制”一些命令。

内嵌 Lua 的执行

好在 Redis 内嵌了 Lua 执行环境，支持 Lua 脚本。通过 Lua 脚本，可以把多个命令复合在一起，完美解决前面提到的命令次序性和服务端计算问题。

Lua

Lua 是一种简洁、轻量、可扩展的脚本语言，特点包括：

• 轻量：源码包只有核心库，编译后体积很小。
• 高效：用 ANSI C 写的，启动快、运行快。
• 内嵌：能嵌入各种编程语言或系统中，提升静态语言的灵活性。比如 OpenResty 就是把 Lua 嵌入到 nginx 里执行。

语法也不用担心，Lua 简单到分分钟就能上手。

执行步骤

Redis 从 2.6 版本开始，启动时会创建 Lua 环境、载入 Lua 库、定义 Redis 全局表格、存储 redis.pcall 等命令，为后续执行做好准备。

一个典型的 Lua 脚本执行步骤：

1. 检查脚本是否执行过，没执行过则用 sha1 校验和生成一个 Lua 函数；
2. 为函数绑定超时和错误处理钩子；
3. 创建一个伪客户端，通过它执行 Lua 中的 Redis 命令；
4. 处理伪客户端的返回值，最终返回给真正的客户端。

交互时序如图：

虽然 Lua 脚本用的是伪客户端，但 Redis 处理它跟普通客户端一模一样，执行的 Redis 命令也会写入 RDB、AOF，并同步到主从复制。

使用

Lua 脚本通过 EVAL 和 EVALSHA 命令来执行。

EVAL 适合单次执行，执行前会由脚本内容生成 sha1 校验和，在函数表里查询是否已定义。如果没定义，执行成功后 Redis 会把校验和作为函数名缓存到全局表，下次执行同样的脚本就不会再创建新函数了。

EVALSHA 则要先通过 SCRIPT LOAD 把函数加载到 Redis，拿到返回的 sha1 校验和，之后直接用它执行命令。

看几个例子：

127.0.0.1:6379> EVAL "return 'hello'" 0 0
"hello"

127.0.0.1:6379> SCRIPT LOAD "return redis.pcall('GET', ARGV[1])"
"20b602dcc1bb4ba8fca6b74ab364c05c58161a0a"

127.0.0.1:6379> EVALSHA 20b602dcc1bb4ba8fca6b74ab364c05c58161a0a 0 test
"zbs"

EVAL 命令的原型是 EVAL script numkeys key [key ...] arg [arg ...]，在 Lua 函数内部用 KEYS[N] 和 ARGV[N] 引用键和参数。注意 KEYS 和 ARGV 的序号都是从 1 开始的。另外要留意：在 Lua 脚本中，Redis 返回空时结果是 false，而不是 nil。

Lua 脚本实例

下面写几个实例，主要是介绍语法，具体应用可以灵活扩展。

场景一：Redis 里 hashSet A 的字段 B 的值是 C，取出 Redis 里键为 C 的值。

// 使用: EVAL script 2 A B
local tmpKey = redis.call('HGET', KEYS[1], KEYS[2]); 
return redis.call('GET', tmpKey);

场景二：一次 lpop 出多个值，直到值为 n 或 list 为空（pipeline 也能轻易实现）。

// 使用: EVAL script 2 list count
local list = {};
local item = false;
local num = tonumber(KEYS[2]);
while (num > 0)
do
  item = redis.call('LPOP', KEYS[1]);
  if item == false then
    break;
  end;
  table.insert(list, item);
  num = num - 1;
end;
return list;

场景三：获取 zset 内 score 最多的 n 个元素，以及它们对应 hashset 中的详细信息。

local elements = redis.call('ZRANK', KEYS[1], 0, KEY[2]);
local detail = {};
for index,ele in elements do
  local info = redis.call('HGETALL', ele);
  table.insert(detail, info);
end;
return detail;

基本语法就是这样，具体怎么用就看场景了。

一些思考

使用场景

总结一下 Redis 里 Lua 的主要使用场景：

• 用 Lua 实现原子性操作，避免不同客户端访问 Redis 造成的数据冲突。
• 前后多次请求的结果有依赖时，用 Lua 把多个请求整合成一个，减少网络往返。

注意点

用 Lua 脚本时，有几个地方需要特别留意：

• 安全性：不要在脚本里使用全局变量，会污染 Lua 环境。虽然用了全局变量会报错、脚本终止，但最好在定义变量时加 local 关键字。
• 时间复杂度：Redis 单线程会阻塞在 Lua 脚本执行中，脚本不能太耗时。
• 原子操作的回滚：如果 Lua 脚本报错，已执行的命令无法回滚。
• 与 pipeline 的选择：一次发出多个 Redis 请求，且前后无依赖时，用 pipeline 比 Lua 脚本更方便。

小结

最近工作变动很大，从业务到技术栈都跟以前完全不同。代码和业务都脱离了掌控，感觉确实不爽——每天“开局一个搜索引擎，语法全靠查”，晚上还得熬夜熟悉新东西，累是肯定的。换工作就是找罪受，但走出舒适区后的充实感也在提醒自己在进步，倒也挺有成就感的。

刚接触新东西没什么沉淀，不想写《带你三天精通 Ja va》这种水文，工作之余的时间都拿去补技术栈了，也没空研究自己觉得有意思的东西。写文章需要素材，为了不砸招牌，最近可能更得少一些。

以上就是这篇文章的全部内容。希望本文对大家的学习或工作有参考价值，有问题欢迎交流，感谢支持。