再也不用为搜索单装 ES 了！Redis 官方这个模块，2 核 4G 跑出 12.5K QPS

👉这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：

• 《项目实战（视频）》：从书中学，往事上“练”

• 《互联网高频面试题》：面朝简历学习，春暖花开

• 《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题

• 《精进 Java 学习指南》：系统学习，互联网主流技术栈

• 《必读 Java 源码专栏》：知其然，知其所以然

👉这是一个或许对你有用的开源项目

国产Star破10w的开源项目，前端包括管理后台、微信小程序，后端支持单体、微服务架构

RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能：

• 多模块：https://gitee.com/zhijiantianya/ruoyi-vue-pro

• 微服务：https://gitee.com/zhijiantianya/yudao-cloud

• 视频教程：https://doc.iocoder.cn

【国内首批】支持 JDK17/21+SpringBoot3、JDK8/11+Spring Boot2双版本

• 反向定位：90% 项目其实不需要 ES

• 横向对比：4 个搜索方案怎么选

• 性能实测：吞吐 4 倍、内存 1/10

• Docker 一行装，4 条命令验证

• Java 接入：Jedis 4.0+ 直接用

• 4 个真实使用边界

• 最后说一句

反向定位：90% 项目其实不需要 ES

Java 项目里只要谈到「搜索」，不假思索的答案永远是 ES——上 Elasticsearch、Logstash、Kibana 三件套。这个组合是好，但它为大数据规模的全文检索 / 日志分析而设计。

90% 的中后台项目其实只要：

• 商品名 / 文章标题模糊搜索；

• 几张表的中文分词检索；

• 类目过滤 + 关键词组合查询；

• 偶尔的同义词、拼写纠错。

这种规模上 ES 是「拿火箭炮打蚊子」——一台 ES 节点起步要 1 GB 内存，多语言、聚合、分布式、副本、shard 一整套配下来你大半都用不到。真正的痛点是：你要为搜索单独维护一个 ES 集群、配 IK 分词、写同步脚本、跟着业务表迭代 mapping。

直接给方案：Redis 官方推出的搜索模块RediSearch——它不是「另一个搜索引擎」，而是 Redis 的一个 module，跟着 Redis 实例一起跑，没有额外服务、没有额外集群。对已经在用 Redis 的项目，等于零运维成本接入全文搜索。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro

• 视频教程：https://doc.iocoder.cn/video/

横向对比：4 个搜索方案怎么选

不是所有搜索场景都该上 RediSearch。先看自己在哪个象限：

判断很简单：

• 数据 < 50 万行、查询不频繁：MySQL FULLTEXT 即可，别造方案；

• 已经用 Redis、数据百万到千万、单机够用：RediSearch 性价比最高；

• 真正的大数据 / 复杂聚合 / 多副本 / 分布式：ES 还是必选；

• 一个新项目、想要现代搜索体验：MeiliSearch / Typesense 也值得看。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud

• 视频教程：https://doc.iocoder.cn/video/

性能实测：吞吐 4 倍、内存 1/10

官方做了一组对比测试，机器配置：

数据源（同样的语料导入）：

RediSearch 配置：

Elasticsearch 配置：

版本：

索引构建：RediSearch 221 秒 vs Elasticsearch 349 秒，领先 58%：

查询吞吐：32 客户端并发跑两词搜索——RediSearch 12.5K ops/sec，ES 仅 3.1K ops/sec，4 倍差距；延迟 8 ms vs 10 ms：

最关键的是内存：低配 2 核 4 GB 服务器上，Redis Stack 镜像（Redis + RediSearch 模块）总内存占用不到 100 MB，ES 实例至少 1 GB。原本要单独申请一台 ES 服务器的预算，现在零成本搞定。

RediSearch 2.0+ 比 1.6 又把吞吐和延迟提升了 2.4 倍。

Docker 一行装，4 条命令验证

装：

docker run -d --name redis-stack-server -p 6379:6379 redis/redis-stack-server:latest # 带密码版 docker run -e REDIS_ARGS="--requirepass redis-stack" \ -p 6379:6379 redis/redis-stack:latest

验证模块装好：

redis-cli -h localhost > MODULE list 3) 1) "name" 2) "search" 3) "ver" 4) "20809"

看到search模块即装好。

4 条核心命令完成搜索全流程：

# 1. 创建索引（hash 数据源、中文分词、goodsName 字段可排序） > FT.CREATE idx:goods ON HASH PREFIX 1 "goods:" \ LANGUAGE chinese SCHEMA goodsName TEXT SORTABLE "OK" # 2. 写入数据（直接 hset，索引自动构建） > HSET goods:1001 goodsName 小米手机 > HSET goods:1002 goodsName 华为手机 # 3. 搜索 > FT.SEARCH idx:goods "手机" 1) "2" 2) "goods:1001" 3) 1) "goodsName" 2) "小米手机" 4) "goods:1002" 5) 1) "goodsName" 2) "华为手机" # 4. 删索引（不删源数据） > FT.DROPINDEX idx:goods

LANGUAGE chinese指定中文分词，SORTABLE让字段可排序。不指定LANGUAGE chinese中文检索就退化成单字匹配，搜索质量直接报废。

Java 接入：Jedis 4.0+ 直接用

Jedis 4.0+ 内置 RediSearch 客户端，不用额外引依赖：

@Bean public UnifiedJedis unifiedJedis(GenericObjectPoolConfig poolConfig) { if (StringUtils.isNotEmpty(password)) { return new JedisPooled(poolConfig, host, port, timeout, password, database); } return new JedisPooled(poolConfig, host, port, timeout, null, database); }

创建索引（与 SQL 建表对应）：

Schema schema = new Schema() .addSortableTextField("goodsName", 1.0) .addSortableTagField("tag", "|"); IndexDefinition rule = new IndexDefinition(Type.HASH) .setPrefixes("goods:") // 与 CLI 端 PREFIX 1 "goods:" 保持一致 .setLanguage("chinese"); // 中文分词 String idxName = "idx:goods"; client.ftCreate(idxName, IndexOptions.defaultOptions().setDefinition(rule), schema);

注意：索引名（idx:goods）和数据 key 前缀（goods:）是两件事——前者是索引身份证，后者是索引盯的 hash key。别把索引名当 key 前缀用。

写入索引（写 hash 即同步入索引）：

public boolean addGoodsIndex(Goods goods) { Map<String, String> hash = MyBeanUtil.toMap(goods); hash.put("_language", "chinese"); // key 必须以索引绑定的前缀「goods:」开头，否则不会被索引 client.hset("goods:" + goods.getGoodsId(), hash); return true; }

中文搜索（带分页 / 排序）：

public SearchResult search(String idxName, SearchObjVO vo, Page<?> page) { String queryKey = String.format("@goodsName:(%s)", vo.getKeyword()); Query q = new Query(queryKey).setLanguage("chinese"); if (StringUtils.isNotBlank(vo.getSidx())) { q.setSortBy(vo.getSidx(), Constants.SORT_ASC.equals(vo.getOrder())); } q.limit((int) page.offset(), (int) page.getSize()); return client.ftSearch(idxName, q); }

关键设计：写 Redis 的代码就是业务现有的 hash 写入代码——只要规范 key 前缀（goods:），索引就自动跟着 hash 写入实时更新，不用单独维护 ES 同步管道。

4 个真实使用边界

边界 1：开源版没有集群（最常见）

RediSearch开源版只支持单实例——集群版只在 Redis 企业版（付费）里有。如果你的搜索数据量超过单机内存上限，必须考虑 Redis 企业版或回到 ES。这是这个工具最大的边界，先确认你的数据规模再决定。

边界 2：拼音转中文不支持（常见）

ES + IK 分词器有「拼音转中文」插件（pinyin），用户输入xiaomi能搜出「小米」。RediSearch 内置中文分词但没有拼音插件，需要自己在应用层做拼音转写。电商搜索这是硬需求，要提前评估。

边界 3：重启后索引要重建（少见但破坏力大）

RediSearch 2.0 起，索引本身会跟着 Redis 持久化文件一起 dump，但 RDB 加载时仍要做一次「索引重建」——百万级数据大约 3-5 分钟，期间搜索服务不可用。修法有两条独立选择：

• 走 AOF 持久化 + everysec 同步（appendonly yes/appendfsync everysec）——重启时 replay AOF 比 RDB 重建索引快得多，但写入 IO 会高一些；

• 维持 RDB（save 60 1000等）+搜索请求走主从分离——主重启的几分钟由从节点顶上，搜索可用性不中断。

别把 AOF 和 RDB 混着写——save 60 1000是 RDB 快照配置，appendonly yes才是 AOF 开关，两者是独立的持久化策略。

边界 4：和业务 hash 共享 key 空间（高级场景）

HSET goods:1001 ...既是业务数据也是索引源——业务侧误删 key 等于删索引数据。修法：用专属前缀（idx:goods:1001）隔离，或加权限控制。

最后说一句

搜索方案的选择不是「哪个最强」，是「哪个最匹配你的规模」。RediSearch 不是来替代 ES 的——它是为「90% 项目其实不需要 ES」这件事提供的更轻方案。好的搜索基础设施不是功能最多的那个，是让你不用为搜索单独维护一个集群的那个。

仓库：github.com/RediSearch/RediSearch

欢迎加入我的知识星球，全面提升技术能力。

👉 加入方式，“长按”或“扫描”下方二维码噢：

星球的内容包括：项目实战、面试招聘、源码解析、学习路线。

文章有帮助的话，在看，转发吧。 谢谢支持哟 (*^__^*）