技术深度解析
Redis二级索引模块（redis-modules-secondary）建立在一个看似简单的理念之上：允许Redis对哈希数据结构中的任意字段建立索引，然后通过范围条件、等值检查以及`COUNT`、`SUM`、`AVG`等基本聚合操作来查询这些索引。在底层，该模块为每个索引字段实现了一个跳表数据结构，维护排序顺序以支持类似`ZRANGEBYSCORE`的查询。考虑到Redis已在有序集合中使用跳表，这是一个自然的选择。
架构亮点：
- 索引创建： 使用`FT.CREATE idx ON HASH PREFIX 1 "user:" SCHEMA age NUMERIC SORTABLE`命令，模块会解析模式，为`age`字段创建一个内存跳表，并在所有针对指定前缀键的`HSET`命令上注册一个钩子。
- 写入路径： 每次执行`HSET`时，模块会提取索引字段，更新跳表（插入/删除），并维护从Redis键到其索引条目的反向映射。这引入了不可忽视的写放大：每次索引字段更新都会触发跳表中的O(log n)操作。
- 查询执行： 像`FT.SEARCH idx "@age:[18 65]"`这样的查询会遍历跳表，收集匹配的键并返回结果。范围查询效率较高（O(log n + k)，其中k为结果数量），但多字段查询需要对多个跳表进行交集运算，在最坏情况下可能退化为O(n)。
- 内存开销： 每个索引字段在跳表中存储字段值的副本，加上指针。对于100万用户且每个用户有3个索引字段的数据集，开销可能超过200 MB——对于内存受限的Redis部署来说相当可观。
与RediSearch的对比：
| 特性 | 二级索引模块 | RediSearch（当前版本） |
|---|---|---|
| 索引类型 | 跳表（排序） | 倒排索引 + 压缩位图 |
| 全文搜索 | 不支持 | 支持（词干提取、模糊搜索、语音搜索） |
| 聚合功能 | 基础（COUNT, SUM, AVG） | 高级（GROUP BY, SORTBY, APPLY, REDUCE） |
| 多字段查询 | 跳表交集 | 位图并集/交集（每个词条O(1)） |
| 内存效率 | 每个索引值约200字节 | 每个词条约40字节（压缩后） |
| 查询延迟（100万文档） | 范围查询5-15毫秒 | 全文搜索1-3毫秒 |
| 写入吞吐量 | 单字段约10K ops/sec | 单字段约50K ops/sec |
数据要点： 二级索引模块的跳表方法虽然优雅，但在搜索工作负载上存在根本性局限。RediSearch的倒排索引和位图压缩将内存开销降低了5倍，查询延迟提升了3-5倍，使其成为明确的继任者。
开源参考： 原始模块代码仍保留在GitHub上的`RediSearch/RediSearch`仓库中（目前12.5k星标）。`src/module-secondary/`目录包含遗留实现。开发者仍可出于教育目的编译它，但不建议用于生产环境。
关键参与者与案例研究
Redis Labs（现为Redis Inc.） 是主要开发者。二级索引模块是Redis模块化更广泛努力的一部分，与`RedisJSON`、`RedisGraph`和`RedisTimeSeries`等模块并列。团队包括Dvir Volk（RediSearch首席工程师）和Itamar Haber（首席架构师），他们在认识到该模块的局限性后，完全转向了RediSearch。
案例研究：电商实时库存
一家中型电商平台曾尝试使用二级索引模块来驱动实时库存筛选器：“显示所有类别为‘电子产品’、价格在50到200美元之间且库存大于0的商品。”他们为每个产品哈希的`category`、`price`和`stock`字段建立了索引。最初，对于50万件商品，查询在2-3毫秒内返回。然而，当规模扩展到500万件商品时，写入延迟成为问题：每次库存更新（价格变动、库存减少）都会触发三次跳表更新，导致写入吞吐量从20K/sec下降到4K/sec。他们最终迁移到了RediSearch，在相同硬件上处理了50K writes/sec。
当时的竞品方案：
| 方案 | 索引方法 | 延迟（p99） | 最大数据集 | 成本（每100万文档） |
|---|---|---|---|---|
| Redis二级索引 | 跳表 | 10毫秒 | 1000万 | $0.50（内存） |
| RediSearch | 倒排位图 | 2毫秒 | 1亿+ | $0.80（内存） |
| Elasticsearch | BKD树 + 倒排索引 | 15毫秒 | 10亿+ | $2.00（磁盘+内存） |
| MongoDB (2dsphere) | B树 | 20毫秒 | 5亿 | $1.50（磁盘） |
数据要点： 二级索引模块提供了最低的成本，但牺牲了可扩展性和功能深度。RediSearch在Redis原生工作负载中取得了最佳平衡，而Elasticsearch仍然是复杂大规模搜索的黄金标准。
行业影响与市场动态
二级索引模块的失败是Redis生态系统的一个关键学习时刻。它表明，一个简单的键值存储无法轻易地……