推荐一个比ES快5倍的搜索引擎

前言

对于后端程序员来说，一提到搜索引擎技术，大家第一个想到的可能是ElasticSearch。

但ElasticSearch有三个让人头疼的点：

ES集群运维太复杂了，光调JVM参数就要花费很多时间。
查询延迟不稳定，经常超时。
硬件成本高，3个节点每月光服务器费用就不少。

那么，问题来了：有没有更轻量级的搜索引擎呢？

答：有，可以使用Redis Search。

你可能会愣一下："Redis还能做搜索？"

这个反应其实很正常。

很多人对Redis的认知还停留在"缓存"和"KV存储"的阶段。

但如果你还这么想，那就真的落后了。

Redis Search是Redis官方推出的全文搜索引擎模块，它直接在Redis内存数据库上构建了高效的搜索功能。

实测QPS能达到2万以上，延迟稳定在5毫秒内。

在相同硬件条件下，Redis Search的QPS是Elasticsearch的3-5倍，而内存占用仅为后者的三分之一。

今天这篇文章，我就把Redis Search为什么值得关注的原因，从头到尾给你拆解一遍。

希望对你会有所帮助。

更多项目实战在Java突击队网：susan.net.cn/project

Redis Search是Redis官方基于RediSearch模块构建的全文搜索引擎，它直接运行在Redis的内存数据库之上。

你可以理解成：在Redis里面"内置"了一个搜索引擎。

它的核心能力包括全文搜索、二级索引、聚合分析、地理空间搜索和向量相似度搜索。

一句话说清：Redis Search让Redis从一个缓存中间件，变成了一个能跑搜索、能建索引、能做向量检索的"全能型选手"。

早在2021年，Redis就通过RediSearch模块提供了搜索能力。

2026年，Redis 8.0将搜索能力进一步整合进核心，Redis Search允许用户将Redis用作文档数据库、向量数据库、二级索引和搜索引擎。

它和Elasticsearch最本质的区别在于架构。

Elasticsearch基于磁盘的Lucene索引构建，数据存在磁盘上，通过内存映射文件来加速访问。

Redis Search的索引全量在内存中，查询时没有磁盘I/O，直接走内存访问。

这个差异直接决定了两者在延迟上的本质区别。

在深入代码之前，我们先建立一个整体认知。

从这张图可以看到，Redis Search的架构非常"轻"------它不依赖任何外部组件，所有索引和查询都在Redis进程内部完成。

索引直接建在Redis的Hash或JSON文档上，查询时直接从内存读取。

三、性能到底有多炸裂？

直接看数据。

3.1 官方基准测试

Redis官方在博客中公布了对OpenSearch（Elasticsearch的关联分支）的基准测试结果：

测试场景	Redis vs OpenSearch 性能优势
单客户端向量搜索	快18倍
多客户端QPS	高52倍
查询延迟	低106倍

也就是说，在向量搜索场景下，Redis Search的吞吐量是OpenSearch的52倍 ，延迟只有OpenSearch的百分之一。

3.2 第三方实测数据

根据第三方实测数据，在相同硬件条件下：

指标	Redis Search	Elasticsearch
索引更新时间	50ms	2s
搜索延迟(P99)	1.2ms	45ms
内存消耗(1TB数据)	8GB	24GB
并发连接数上限	50,000	5,000

索引更新快40倍，延迟低37倍，内存省三分之二，并发连接多10倍。

这组数据足以说明：对于需要实时搜索、低延迟、高并发的场景，Redis Search的优势是碾压级的。

3.3 为什么能这么快？

三个核心原因：

第一，内存索引。

Elasticsearch的索引存在磁盘上，查询需要走磁盘I/O或依赖文件系统缓存。

Redis Search的索引全量常驻内存，查询直接走内存访问，没有磁盘开销。

第二，无索引合并开销。

Elasticsearch的Lucene索引需要定期进行段合并（Segment Merge），这个过程会消耗大量CPU和I/O，影响查询性能。

Redis Search的索引是增量更新的，没有段合并的开销。

第三，多线程查询。

Redis Search支持多线程查询执行，可以充分利用多核CPU。

在Redis 8.0中，查询处理能力进一步提升，支持16倍的查询处理能力扩展。

光说理论不够，我们来看怎么用。

4.1 部署Redis Stack

Redis Search作为Redis Stack的一部分提供。最简单的方式是用Docker：

bash 复制代码

docker run -d --name redis-stack -p 6379:6379 redis/redis-stack:latest

4.2 创建索引

bash 复制代码

# 创建商品索引
FT.CREATE idx:products ON HASH PREFIX 1 product: SCHEMA 
    name TEXT WEIGHT 5.0 
    description TEXT 
    price NUMERIC 
    category TAG 
    embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE

这个命令创建了一个名为idx:products的索引，索引的是以product:为前缀的Hash文档。

包含三个字段：name（全文搜索，权重5）、description（全文搜索）、price（数值范围查询）、category（标签精确匹配）和embedding（768维向量索引）。

4.3 添加文档

bash 复制代码

# 添加商品数据
HSET product:1 name "iPhone 15 Pro" description "苹果旗舰手机，钛金属边框" price 8999 category "手机"
HSET product:2 name "MacBook Pro" description "苹果笔记本电脑，M3芯片" price 15999 category "电脑"
HSET product:3 name "AirPods Pro" description "苹果降噪耳机" price 1899 category "耳机"

4.4 执行搜索

bash 复制代码

# 全文搜索：搜索包含"苹果"的商品
FT.SEARCH idx:products "苹果" LIMIT 0 10 RETURN 3 name price category

# 条件搜索：手机分类且价格低于10000
FT.SEARCH idx:products "@category:{手机} @price:[0 10000]" RETURN 3 name price category

# 中文搜索
FT.SEARCH idx:products "苹果手机" LANGUAGE chinese HIGHLIGHT SUMMARIZE

4.5 向量搜索（语义搜索）

向量搜索是Redis Search在AI时代最核心的能力之一。

它把文本转换成向量，通过计算向量之间的距离来找到语义上最相似的内容。

bash 复制代码

# 创建带向量索引的商品
FT.CREATE idx:products_vector ON JSON PREFIX 1 product: SCHEMA 
    $.name AS name TEXT 
    $.embedding AS embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 384 DISTANCE_METRIC COSINE

# 向量相似度搜索
FT.SEARCH idx:products_vector "*"=>[KNN 5 @embedding $query_vec AS score] 
    PARAMS 2 query_vec <向量数据> 
    SORTBY score 
    DIALECT 2

混合搜索（Hybrid Search） 是Redis 8.8及以上的杀手级功能，它把关键词匹配和语义向量搜索结合起来：

bash 复制代码

# 关键词 + 向量混合搜索
FT.HYBRID idx:products_vector "无线降噪耳机" 
    KNN 5 @embedding $query_vec 
    PARAMS 2 query_vec <向量数据>

在Spring Boot项目中集成Redis Search也非常简单。

5.1 添加依赖

bash 复制代码

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>com.redis</groupId>
    <artifactId>redis-modules-java</artifactId>
    <version>1.0.0</version>
</dependency>

5.2 配置Redis连接

bash 复制代码

spring:
  data:
    redis:
      host: localhost
      port: 6379

5.3 搜索服务实现

bash 复制代码

@Service
public class ProductSearchService {
    
    @Autowired
    private StringRedisTemplate redisTemplate;
    
    public List<Product> searchProducts(String keyword, String category, Double minPrice, Double maxPrice) {
        StringBuilder query = new StringBuilder();
        
        // 关键词搜索
        if (keyword != null && !keyword.isEmpty()) {
            query.append("@name:").append(keyword);
        }
        
        // 分类过滤
        if (category != null && !category.isEmpty()) {
            if (query.length() > 0) query.append(" ");
            query.append("@category:{").append(category).append("}");
        }
        
        // 价格范围
        if (minPrice != null || maxPrice != null) {
            if (query.length() > 0) query.append(" ");
            query.append("@price:[");
            query.append(minPrice != null ? minPrice : 0);
            query.append(" ");
            query.append(maxPrice != null ? maxPrice : Double.MAX_VALUE);
            query.append("]");
        }
        
        // 执行搜索
        List<String> results = redisTemplate.execute(
            (RedisCallback<List<String>>) connection -> {
                return connection.execute(
                    "FT.SEARCH", 
                    "idx:products", 
                    query.toString(), 
                    "LIMIT", "0", "10",
                    "RETURN", "3", "name", "price", "category"
                );
            }
        );
        
        return parseResults(results);
    }
}

对比维度	Redis Search	Elasticsearch
数据存储	全内存	磁盘 + 内存缓存
查询延迟	<5ms	20-100ms
索引更新	50ms	2s
QPS（同硬件）	3-5倍于ES	基准
内存占用	1/3于ES	基准
部署复杂度	极低	高（需调JVM/分片/生命周期）
运维成本	极低	高
中文分词	Friso分词器	IK Analyzer
向量检索	✅ HNSW/FLAT	✅
混合搜索	✅ FT.HYBRID（8.8+）	✅
数据规模上限	受内存限制	可PB级
排序/相关性调优	基础BM25	高级（函数评分/学习排序）

核心差异可以概括为三句话：

Redis Search给的是"极致的快"------内存级延迟、毫秒级响应
Redis Search给的是"极简的运维"------没有分片、没有段合并、没有JVM调优
Redis Search给的是"实时的更新"------数据写入后50ms内即可被搜索到

七、优缺点

优点

1. 性能碾压

在相同硬件条件下，QPS是Elasticsearch的3-5倍。向量搜索场景下，吞吐量最高可达52倍。

2. 延迟极低

P99延迟稳定在1.2ms左右。对于实时搜索场景，这是一个巨大的优势。

3. 部署极简

不需要额外搭建搜索集群，直接在Redis中启用即可。运维成本接近于零。

4. 实时更新

数据写入后50ms内即可被搜索到。商品上架、价格变更、库存变化，用户几乎瞬间就能搜到最新状态。

5. 内存高效

在相同数据量下，内存占用仅为Elasticsearch的三分之一。

6. 原生向量检索

支持HNSW和FLAT两种向量索引算法，完美适配RAG和AI应用场景。

7. 混合搜索

Redis 8.8+支持FT.HYBRID命令，关键词匹配和语义向量搜索可以同时进行。

缺点

1. 数据规模受内存限制

Redis Search的索引全量在内存中。如果你的数据量超过可用内存，就不太适合用Redis Search。

2. 高级排序能力有限

Elasticsearch支持函数评分、衰减函数、学习排序等复杂排序逻辑。Redis Search的排序能力相对基础。

3. 中文分词生态不如ES

Redis Search默认采用Friso分词器，而Elasticsearch的IK Analyzer更成熟。

4. 不适合PB级数据

Elasticsearch支持跨集群搜索和冷热数据分层，可处理PB级数据。Redis Search适合TB级以内的数据集。

八、适用场景

场景	推荐程度	理由
电商商品搜索	✅✅✅ 强烈推荐	高并发、低延迟、实时更新
实时推荐系统	✅✅✅ 强烈推荐	亚毫秒级响应，实时索引更新
RAG / 向量检索	✅✅✅ 强烈推荐	原生向量索引+混合搜索
API网关/微服务路由	✅✅✅ 强烈推荐	轻量级，无需额外组件
中小型文档搜索	✅✅✅ 强烈推荐	数据量在内存范围内时性价比极高
中文搜索（严格）	⚠️ 需评估	分词生态不如ES，需实测中文效果
PB级海量数据	❌ 不推荐	Elasticsearch更合适
复杂排序/个性化排序	⚠️ 需评估	ES的高级排序功能更强

更多项目实战在Java突击队网：susan.net.cn/project

九、写在最后

回到最初的问题：为什么值得关注Redis Search？

答案不复杂------因为它用"内存的速度"，重新定义了搜索体验。

Elasticsearch很强大，但它的强大是有代价的------复杂的运维、磁盘I/O的延迟、段合并的CPU开销。

在2026年的今天，当内存价格不断下降、当AI应用对延迟的要求越来越高，Redis Search的"全内存架构"正在成为一个越来越有吸引力的选项。

你不需要为了搜索能力，去维护一套独立的Elasticsearch集群。搜索能力直接在Redis里，跟你现有的缓存、会话、计数器在同一个地方。

Redis 8.0已经把搜索能力深度整合进核心，Redis 8.8又推出了FT.HYBRID混合搜索。

Redis Search正在从一个"附加模块"，变成Redis的"核心能力"。

如果你正在被Elasticsearch的运维复杂度困扰，如果你的搜索数据量在TB级以内，如果你追求毫秒级的响应速度------Redis Search值得你尝试一下。

Docker一条命令启动，几行FT.CREATE创建索引，几行FT.SEARCH开始搜索。

你会发现------搜索，可以这么轻、这么快。