Redis Array数据类型详解：18个新命令与浏览器Playground体验

Redis 迎来全新 Array 数据类型

Redis 的创始人 Salvatore Sanfilippo（antirez）近日向 Redis 提交了一个重磅 PR，为 Redis 引入了一种全新的数据类型——Array（数组）。这不仅是 Redis 数据模型的一次重要扩展，更值得关注的是，这一功能的开发过程大量借助了 AI 辅助编程。另一边，Simon Willison 利用 Claude Code 构建了一个基于 WebAssembly 的浏览器端交互式实验场，让开发者无需安装任何环境即可体验这些新命令。

Redis 自 2009 年诞生以来，逐步构建了一套丰富的数据类型体系。从最初的 String（字符串）、List（列表）、Set（集合）、Sorted Set（有序集合）和 Hash（哈希），到后来陆续加入的 HyperLogLog（基数估算）、Stream（消息流）、Bitmap（位图）等，每一种数据类型都针对特定的使用场景进行了高度优化。Redis 的设计哲学始终围绕其单线程事件驱动架构展开——所有命令在一个主线程中串行执行，这意味着每个数据结构操作都必须足够快速，否则会阻塞后续所有请求。正因如此，Redis 在数据类型的选择上极为审慎：每种类型都经过精心设计，在内存效率和操作性能之间寻找最优平衡。例如，当元素数量较少时，Redis 会使用紧凑的内存编码格式（早期的 ziplist，Redis 7.0 后统一为 listpack）来减少内存碎片和指针开销；当元素增长到一定阈值后，再自动转换为更适合大规模数据的底层结构。这种「小数据用紧凑编码，大数据用专用结构」的双层设计贯穿了 Redis 几乎所有数据类型。

然而，Redis 一直缺少一种真正意义上的「数组」结构——即支持高效随机访问、固定位置索引、同时具备丰富查询能力的有序集合。现有的 List 类型虽然支持有序存储，但其底层基于 quicklist（压缩列表与双向链表的混合结构）实现，在随机访问性能和功能丰富度上存在局限。Array 类型的引入，正是为了填补这一空白。

Redis Array 的 18 个新命令一览

此次 PR 一口气引入了 18 个新命令，覆盖了数组操作的方方面面：

• 基础读写：ARSET、ARGET、ARMSET、ARMGET 用于单个或批量的元素设置与获取
• 范围操作：ARGETRANGE、ARDELRANGE 支持对数组的区间读取和删除
• 查询与遍历：ARSCAN、ARSEEK、ARNEXT 提供了游标式的遍历能力
• 信息与统计：ARLEN、ARINFO、ARCOUNT 获取数组长度、元信息和计数
• 插入与删除：ARINSERT、ARDEL 实现灵活的元素增删
• 高级功能：AROP（运算操作）、ARRING（环形缓冲）、ARLASTITEMS（获取末尾元素）

其中，游标式遍历（ARSCAN、ARSEEK、ARNEXT）的设计延续了 Redis 一贯的遍历哲学。熟悉 Redis 的开发者对 SCAN、HSCAN、SSCAN、ZSCAN 这一命令族不会陌生——它们通过返回游标（cursor）的方式实现增量式遍历，避免了像 KEYS 或 SMEMBERS 那样一次性返回全部数据可能导致的阻塞问题。

这一设计背后有着深刻的工程考量。Redis 的 SCAN 命令使用了一种被称为反向二进制迭代（reverse binary iteration） 的游标推进算法：游标值并非简单的自增序号，而是通过对哈希表槽位的高位递增来生成下一个游标。这种看似反直觉的设计解决了一个棘手的问题——在遍历过程中，如果哈希表发生了 rehash（扩容或缩容），传统的顺序遍历可能会遗漏元素或重复返回元素，而反向二进制迭代算法能保证：即使底层数据结构在遍历期间发生了变化，所有元素最终都会被访问到（可能有少量重复，但不会遗漏）。这一保证在不使用任何锁的前提下实现，完美契合了 Redis 单线程无锁的架构特性。

Array 的遍历命令同样采用了这种模式：ARSCAN 启动遍历并返回游标，ARSEEK 将游标定位到指定位置，ARNEXT 则基于游标逐步推进。这种设计在处理大规模数组时尤为重要，它确保了即使数组包含数百万个元素，遍历操作也不会阻塞 Redis 的单线程事件循环。

ARRING（环形缓冲） 命令背后是一个经典的数据结构概念——环形缓冲区（Ring Buffer，也称循环缓冲区）。环形缓冲区使用固定大小的内存空间，当写入指针到达末尾时自动回绕到起始位置，覆盖最旧的数据。这种结构在系统编程中应用极为广泛：操作系统内核的日志缓冲区（如 Linux 的 dmesg）、网络数据包的收发队列、音视频流的帧缓冲等都依赖环形缓冲区。

环形缓冲区之所以在高性能系统中如此受欢迎，关键在于它的两个特性：固定内存占用和无需数据搬移。传统数组在头部删除元素时需要将后续所有元素前移，时间复杂度为 O(N)；而环形缓冲区只需移动读指针，操作始终为 O(1)。在无锁编程（lock-free programming）领域，单生产者-单消费者（SPSC）的环形缓冲区甚至可以在不使用任何互斥锁或原子操作的情况下实现线程安全的数据传递，这使其成为高频交易系统、实时音频处理等对延迟极度敏感的场景中的首选数据结构。值得注意的是，Redis 现有的 Stream 类型也提供了类似的容量限制功能——通过 XADD 命令的 MAXLEN 参数可以限制消息流的最大长度，自动裁剪旧消息。但 ARRING 在语义上更加直接：它将环形缓冲区作为一等公民暴露给用户，操作更加轻量，适合不需要 Stream 复杂消费者组机制的简单场景。

在 Redis 的应用场景中，ARRING 非常适合实现固定容量的最近事件记录、滑动窗口统计、实时监控数据的最新 N 条记录等功能，无需开发者手动维护数组大小和元素淘汰逻辑。

这套命令集的设计经过深思熟虑，既保持了 Redis 一贯的命令风格简洁性，又提供了足够丰富的操作语义。

ARGREP 命令：Redis 服务端正则搜索

在所有新命令中，ARGREP 无疑是最引人注目的。它允许在服务端直接对数组中的值执行 grep 式的正则匹配搜索，底层集成了 TRE 正则表达式库。

TRE 是由芬兰开发者 Ville Laurikari 编写的一个轻量级 POSIX 兼容正则表达式库，其最大的特色在于支持近似匹配（approximate matching）——即允许在匹配时容忍一定程度的编辑距离（插入、删除、替换字符），这在模糊搜索场景中极具价值。

要理解 TRE 的技术选型意义，需要了解正则引擎的两大流派。主流正则引擎分为 NFA（非确定性有限自动机） 和 DFA（确定性有限自动机） 两种实现方式。大多数编程语言（如 Python、Java、JavaScript）内置的正则引擎采用 NFA 实现，它通过回溯（backtracking）来尝试所有可能的匹配路径，功能强大但存在一个致命缺陷：当正则表达式包含嵌套量词（如 (a+)+b）或复杂的交替模式时，回溯路径可能呈指数级增长，导致所谓的灾难性回溯（catastrophic backtracking）——一个精心构造的输入字符串可能让匹配耗时从毫秒级暴增到数小时甚至更久，这也是 ReDoS（Regular Expression Denial of Service）攻击的原理基础。DFA 引擎（如 Google 的 RE2）则保证了线性时间复杂度，但不支持反向引用等高级特性。TRE 采用了一种基于标签化 NFA（Tagged NFA, TNFA） 的创新算法，它在保持 POSIX 语义兼容性的同时，通过确定化处理避免了回溯问题，实现了 O(N×M) 的时间复杂度（N 为输入长度，M 为正则表达式长度）。对于 Redis 这样对延迟极度敏感的内存数据库而言，选择 TRE 而非 PCRE（Perl Compatible Regular Expressions）是一个深思熟虑的工程决策——一个恶意构造的正则表达式如果触发灾难性回溯，可能会阻塞 Redis 主线程数秒甚至更久，导致所有客户端请求超时。TRE 从根本上消除了这一风险。

ARGREP 支持丰富的选项组合：

• MATCH：指定匹配模式
• AND / OR：多条件的逻辑组合
• LIMIT：限制返回结果数量
• WITHVALUES：在结果中包含匹配的值
• NOCASE：大小写不敏感匹配

例如命令 ARGREP myarr MATCH CHERRY AND LIMIT 10 WITHVALUES NOCASE 可以在数组 myarr 中搜索包含 "CHERRY" 的元素，忽略大小写，最多返回 10 条结果并附带值内容。

这意味着 Redis 不再只是一个简单的键值存储，而是在数据结构层面具备了初步的搜索能力。对于需要在内存中快速检索文本数据的场景，这是一个极具价值的特性。值得注意的是，Redis 此前已经通过 RediSearch 模块提供了全文搜索能力，但那是一个独立的模块化扩展，需要单独安装和配置，且引入了倒排索引等额外的数据结构和内存开销。而 ARGREP 则是直接内建于核心数据类型中的搜索功能，使用门槛更低，部署也更简单——它不需要预先建立索引，而是在查询时实时扫描数组内容，这种设计在数据量适中（数千到数万条记录）的场景下非常实用。

浏览器端 WebAssembly Playground 使用指南

Simon Willison 的 Redis Array Playground 是一个精巧的工程实践。它将 Redis 的一个子集编译为 WebAssembly，直接在浏览器中运行，配合可视化的命令构建器 UI，让开发者可以：

1. 从左侧边栏选择要尝试的命令
2. 通过下拉菜单和输入框构建命令参数
3. 实时查看生成的完整命令文本
4. 点击运行按钮即时获得执行结果

WebAssembly（简称 Wasm）是一种二进制指令格式，最初由 W3C 标准化，旨在为 Web 平台提供接近原生的代码执行性能。它的核心价值在于：C、C++、Rust 等系统级语言编写的程序可以通过 Emscripten 等工具链编译为 .wasm 模块，然后在浏览器的沙箱环境中安全运行。

Emscripten 是这一生态中最关键的工具链。它本质上是一个基于 LLVM 的编译器后端，能够将 C/C++ 代码编译为 WebAssembly 字节码，同时提供一套对 POSIX API 的模拟层——包括一个基于 JavaScript 的虚拟文件系统（MEMFS/IDBFS）、基于 Web API 的网络模拟，以及对 pthreads 多线程的有限支持（通过 Web Workers 和 SharedArrayBuffer 实现）。然而，这种模拟并非完美：Redis 深度依赖的 epoll/kqueue 等 I/O 多路复用机制、fork() 系统调用（用于 RDB 持久化时的写时复制）、以及 TCP 套接字监听等功能，在浏览器沙箱中要么无法实现，要么需要大幅改造。因此 Playground 运行的是 Redis 的一个功能子集，专注于数据结构操作的核心逻辑，剥离了网络服务、持久化和集群等与操作系统紧密耦合的部分。

这种「将服务端软件搬到浏览器」的方式近年来越来越流行，SQLite 的 Wasm 版本（sql.js）和 PostgreSQL 的 PGlite 都是类似的成功案例。另一个值得关注的发展方向是 WASI（WebAssembly System Interface） 标准——它试图为 WebAssembly 定义一套标准化的系统接口，使 Wasm 模块不仅能在浏览器中运行，还能在服务端、边缘计算节点等任何环境中以统一的方式执行，被 Docker 联合创始人 Solomon Hykes 称为「如果 2008 年就有 WASI，我们就不需要创造 Docker 了」。

这个实验场本身也是 AI 辅助开发的产物——Simon 使用 Claude Code for Web 完成了构建，整个过程记录在 GitHub PR #277 中。

AI 辅助开发的双重印证

这个项目有一个有趣的现象：Redis Array 类型本身就是 AI 辅助开发的成果，而用于体验它的 Playground 工具同样由 AI 辅助构建。

Salvatore 在其博客文章 Redis array type: short story of a long development 中详细记录了 AI 辅助开发 Array 类型的过程。作为 Redis 的创始人，他对 AI 在系统级 C 语言开发中的实际应用给出了第一手的经验分享。

这两个案例共同说明了一个趋势：AI 辅助编程正在从简单的代码补全，走向能够参与复杂系统设计和全栈工具开发的阶段。无论是底层的 C 语言数据结构实现，还是前端的 WebAssembly 交互式应用，AI 都展现出了实质性的生产力贡献。这一趋势与更广泛的行业观察一致——GitHub Copilot 在 2024 年的数据显示，开发者接受 AI 建议的代码比例已超过 30%，而在特定语言（如 Python 和 JavaScript）中这一比例更高。但 Salvatore 的案例更具说服力，因为系统级 C 语言开发通常被认为是 AI 辅助编程最难以胜任的领域之一：它要求对内存管理、指针操作、并发安全等底层细节有精确的把控，容错空间极小。一个微小的缓冲区溢出或 use-after-free 错误就可能导致安全漏洞或数据损坏，而这类错误往往在代码审查和常规测试中难以发现，需要借助 Valgrind、AddressSanitizer 等专业工具才能检测。AI 能够在这一领域提供有效辅助，标志着其代码理解和生成能力已经达到了一个新的水平。

Redis Array 与现有数据结构的对比

目前 Array 类型的实现还在分支阶段，尚未合入主线。但如果最终被采纳，它将填补 Redis 在有序、可索引、支持服务端搜索的数组结构方面的空白：

• 相比 List 类型：Array 提供了更丰富的随机访问和正则搜索能力。Redis 的 List 底层使用 quicklist 实现（Redis 3.2 之后），它本质上是一个由多个 ziplist（压缩列表，Redis 7.0 后改为 listpack）节点组成的双向链表。这种结构对头尾操作（LPUSH/RPUSH/LPOP/RPOP）非常高效，时间复杂度为 O(1)，但按索引随机访问（LINDEX）的时间复杂度为 O(N)，需要从头或尾遍历链表节点。更具体地说，quicklist 的每个节点是一个 listpack（连续内存块），节点之间通过双向指针连接。要访问第 K 个元素，Redis 需要先确定它位于哪个 listpack 节点中（遍历节点链表），然后在该节点内部进行线性扫描。虽然 Redis 会记录每个节点包含的元素数量以加速定位，但在最坏情况下仍然需要遍历多个节点。Array 类型预计在随机访问性能上会有显著改善，可能采用连续内存布局或树形索引结构来实现 O(1) 或 O(log N) 的索引访问。
• 相比 Sorted Set：Array 更适合需要保持插入顺序和位置索引的场景。Sorted Set 通过 score（分数）维护排序，底层使用跳表（Skip List）和哈希表的组合实现，擅长范围查询和排名操作，但不支持按插入位置进行索引访问。跳表是一种概率性数据结构，通过多层索引实现 O(log N) 的查找、插入和删除，Redis 选择跳表而非平衡二叉树（如红黑树）的原因在于跳表实现更简单、范围查询更自然（只需在底层链表上顺序遍历），且并发友好性更好。但 Sorted Set 的排序依据是 score 值而非插入位置，如果需要「第 100 个插入的元素」这样的位置语义，Sorted Set 无法直接满足。
• 独有优势：ARGREP 带来的服务端正则搜索是其他数据类型不具备的

值得一提的是，Redis 在 2024 年 3 月将其许可证从 BSD 三条款许可证变更为 SSPLv1（Server Side Public License）与 RSALv2（Redis Source Available License v2）的双许可模式。这一变更的深层背景是近年来开源商业化领域的核心矛盾：AWS、Google Cloud、Azure 等云服务商可以直接将开源软件作为托管服务提供给用户，获取巨额收入，却无需向原始开发者回馈任何代码或收益。MongoDB 率先在 2018 年采用 SSPL 应对这一问题，Elastic、HashiCorp 等公司随后跟进。SSPL 的核心条款要求：如果你将 SSPL 许可的软件作为服务提供给第三方，你必须将整个服务栈（包括管理、监控、部署等所有相关软件）的源代码以 SSPL 许可开源。这一条款实际上使得云厂商几乎不可能在不开源其整个云平台的情况下提供托管服务，因此 OSI（开源促进会）明确表示 SSPL 不符合开源定义。

这一变更在开源社区引发了广泛讨论，也催生了 Valkey（由 Linux 基金会托管的 Redis 分支）等替代项目。Valkey 从 Redis 7.2.4（最后一个 BSD 许可版本）分叉而来，由 AWS、Google、Oracle、Ericsson 等公司共同支持，承诺维持真正的开源许可（BSD）。目前 Valkey 已经发布了多个独立版本，并开始引入自己的特性分支。Array 类型作为许可证变更后的重要新特性，其最终是否会被 Valkey 等分支项目跟进采纳，也是值得关注的后续动态——由于 Array 类型的代码将在 SSPL/RSALv2 许可下发布，Valkey 无法直接合并这些代码，而需要独立实现类似功能，这可能导致两个项目在数据类型层面出现分化。

对于关注 Redis 发展的开发者来说，现在就可以通过浏览器端的 Playground 提前了解这些新命令的用法，为未来的技术选型做好准备。

核心要点

• Redis 创始人 Salvatore Sanfilippo 提交 PR，为 Redis 新增 Array 数据类型，包含 18 个新命令
• ARGREP 命令支持服务端正则搜索，集成 TRE 正则库，可实现大小写不敏感、多条件组合的数组内容检索
• Simon Willison 利用 Claude Code 构建了基于 WebAssembly 的浏览器端交互式实验场，无需安装即可体验新命令
• Redis Array 类型和 Playground 工具均为 AI 辅助开发的产物，展示了 AI 在系统级和全栈开发中的实际应用
• Array 类型目前处于分支阶段，若合入主线将填补 Redis 在可索引、可搜索数组结构方面的空白