企业官网建设流程全解析

Redis 在大多数团队里一直被当作缓存用，直到有一次我们做一个商品检索功能，数据量大概 800 万条，字段有十几个，需要支持多条件组合过滤加关键词匹配。一开始用 ElasticSearch 搭了一套，查询延迟在 200ms 到 1.5s 之间波动，集群维护成本也不低。后来尝试用 RediSearch 模块替代，同样的查询场景，P99 延迟直接降到了 40ms 以内，吞吐量翻了将近 5 倍。这篇文章就把整个选型、搭建、调优和踩坑过程完整梳理一遍，适合正在做全文搜索方案选型、或者觉得 ES 维护太重想找轻量替代方案的开发者参考。

1. 为什么我开始认真考虑 RediSearch 而不是继续用 ES

1.1 一个真实场景引发的重新评估

先说清楚背景。我们的业务场景是商品搜索，数据模型大概是这样的：每个商品有标题、描述、分类、品牌、价格区间、库存状态、上架时间等字段。用户端的查询需求包括：关键词全文匹配标题和描述、按分类和品牌做过滤、按价格排序、按上架时间倒序。数据量级在 800 万到 1000 万之间，每天有增量更新。

最初选 ES 的理由很充分：成熟、生态好、支持复杂的全文检索和聚合分析。但实际跑起来之后，问题逐渐暴露出来。首先是资源占用，三个节点的集群，每个节点 8 核 16G，JVM 堆内存调优来调优去，GC 还是偶尔抖动。其次是查询延迟不稳定，简单查询还好，一旦涉及多字段组合过滤加上关键词打分排序，延迟就会明显上升。最让人头疼的是运维复杂度，索引重建、分片再平衡、版本升级，每次操作都要小心翼翼。

后来在一个技术社区看到有人提到 RediSearch，说是在特定场景下比 ES 快很多。我一开始是怀疑的，毕竟 ES 在全文搜索领域的地位摆在那里。但仔细研究了一下 RediSearch 的架构之后，发现它的设计思路确实不一样，值得一试。

1.2 RediSearch 到底是什么，和普通 Redis 有什么关系

很多人听到 RediSearch 的第一反应是"Redis 不是做缓存的吗，怎么做搜索"。这里需要澄清一个概念：RediSearch 是 Redis 的一个模块，不是 Redis 本身。Redis 从 4.0 版本开始支持模块系统，允许第三方开发者以动态链接库的形式扩展 Redis 的功能。RediSearch 就是 Redis 官方（后来由 Redis Ltd. 维护）推出的一个搜索模块。

它的核心能力包括：全文索引、二级索引、聚合查询、模糊搜索、同义词支持、中文分词（需要额外配置）。和 ES 最大的区别在于，RediSearch 是内存优先的架构，所有索引数据都放在内存里，查询时不需要像 ES 那样走磁盘检索和缓存加载的流程。这就是它快的主要原因之一。

另一个关键区别是数据模型。ES 是文档型存储，每个文档独立存储和索引；RediSearch 是建立在 Redis 的键值存储之上的，它通过哈希结构存储文档，然后对指定字段建立索引。这意味着如果你的数据已经在 Redis 里了，用 RediSearch 几乎是零迁移成本。

1.3 性能差距的来源：内存索引 vs 磁盘检索

为什么 RediSearch 能比 ES 快这么多？核心原因在于两者的索引结构和查询执行路径完全不同。

ES 的底层是 Lucene，Lucene 的索引是存储在磁盘上的段文件，查询时需要把相关的段加载到文件系统缓存中。虽然 ES 会尽量利用操作系统的页缓存，但一旦数据量超过内存容量，就会发生磁盘 I/O。而且 ES 的查询执行是分布式的，需要协调节点分发查询、收集结果、合并排序，这个过程中网络开销和协调开销不可忽略。

RediSearch 则完全不同。它的索引结构是专门为内存设计的，使用了压缩的倒排索引和跳表结构。查询时直接在内存中遍历索引，没有磁盘 I/O，没有跨节点协调（单节点模式下）。即使是在集群模式下，RediSearch 的查询路径也比 ES 短得多。

我实测过一组对比数据：同样的 800 万条商品数据，同样的查询条件（关键词匹配 + 分类过滤 + 价格排序），ES 的 P50 延迟是 180ms，P99 是 1.2s；RediSearch 的 P50 是 12ms，P99 是 38ms。吞吐量方面，ES 单节点大概能扛 200 QPS，RediSearch 能到 1000 QPS 以上。这个差距在低并发场景下可能感知不明显，但在高并发下就是能不能扛住的问题了。

2. 环境搭建：从零把 RediSearch 跑起来

2.1 安装方式的选择与对比

RediSearch 的安装方式有几种，我分别试过，这里说一下各自的适用场景。

第一种是直接用 Redis Stack。Redis Stack 是 Redis 官方推出的一个打包版本，里面包含了 Redis 核心、RediSearch、RedisJSON、RedisGraph 等模块。安装最简单，Docker 一条命令就能跑起来。适合快速验证和开发环境。

第二种是单独编译 RediSearch 模块，然后加载到已有的 Redis 实例中。这种方式适合生产环境，因为你可以精确控制 Redis 的版本和配置，只加载需要的模块。编译过程稍微麻烦一点，需要先装 CMake、GCC 等工具链。

第三种是用包管理器安装。比如在 Ubuntu 上可以用 apt 安装 redis-stack-server，在 macOS 上可以用 brew 安装 redis-stack。这种方式介于前两者之间，方便程度和可控性都还行。

我个人建议：开发环境直接用 Docker 跑 Redis Stack，生产环境如果已经有 Redis 集群，就单独编译模块加载进去。下面分别说一下具体操作。

2.2 Docker 方式的快速启动

这是最省事的方式，一条命令搞定：

docker run -d --name redis-stack \ -p 6379:6379 \ -p 8001:8001 \ -v /data/redis-stack:/data \ redis/redis-stack:latest

这里解释一下参数。-p 6379:6379是 Redis 的默认端口，-p 8001:8001是 RedisInsight 的端口，RedisInsight 是一个可视化管理工具，后面会讲到。-v是把数据目录挂载到宿主机，避免容器重启后数据丢失。

启动之后可以用redis-cli连接进去，执行MODULE LIST命令，如果能看到search模块，说明 RediSearch 已经加载成功了。

注意：Redis Stack 的镜像比较大，拉取的时候可能需要等一会儿。如果网络环境不好，可以考虑用国内镜像源。

2.3 手动编译模块加载到已有 Redis

如果生产环境已经有 Redis 实例，不想换镜像，可以单独编译 RediSearch 模块。步骤如下：

# 安装编译依赖 apt-get install -y build-essential cmake git # 克隆源码 git clone --recursive https://github.com/RediSearch/RediSearch.git cd RediSearch # 编译 make setup make build # 编译完成后，模块文件在 bin/ 目录下 ls bin/ # 应该能看到 redisearch.so

然后把模块文件拷贝到 Redis 的模块目录，在redis.conf中添加一行：

loadmodule /path/to/redisearch.so

重启 Redis 之后，用MODULE LIST验证一下。

这里有个坑要注意：RediSearch 的版本和 Redis 的版本有兼容性要求。比如 RediSearch 2.x 需要 Redis 6.x 以上，RediSearch 1.x 支持 Redis 4.x 和 5.x。编译之前一定要看清楚版本对应关系，否则加载模块时会报错。

2.4 验证安装是否成功

不管用哪种方式安装，验证步骤都是一样的。连接 Redis 之后执行：

redis-cli MODULE LIST

输出中应该包含类似这样的内容：

1) 1) "name" 2) "search" 3) "ver" 4) (integer) 20405

ver后面的数字是版本号，20405 表示 2.4.5 版本。看到这个就说明 RediSearch 已经正常加载了。

接下来可以做一个简单的功能验证：创建一个索引，插入几条数据，然后查询。

# 创建索引 FT.CREATE product_idx ON HASH PREFIX 1 product: SCHEMA title TEXT WEIGHT 5.0 description TEXT category TAG price NUMERIC SORTABLE # 插入数据 HSET product:1 title "无线蓝牙耳机" description "主动降噪 长续航" category "数码" price 299 HSET product:2 title "有线耳机" description "高保真音质" category "数码" price 99 # 查询 FT.SEARCH product_idx "耳机"

如果能看到返回结果，说明整个链路已经通了。

3. 索引设计：决定搜索性能的关键一步

3.1 字段类型的选择逻辑

RediSearch 支持多种字段类型，每种类型对应不同的索引结构和查询方式。选错类型不仅影响查询结果，还会影响性能。下面是我总结的字段类型选择对照表：

TEXT 类型是最耗资源的，因为它需要分词、建立倒排索引、计算相关性打分。所以只对真正需要全文搜索的字段用 TEXT，比如商品标题和描述。分类、品牌这种精确匹配的字段，用 TAG 类型就够了，查询效率高很多。

NUMERIC 类型用于价格、库存、时间戳这些需要范围查询和排序的字段。加上SORTABLE参数之后，RediSearch 会额外维护一个排序索引，查询时可以直接按这个字段排序，不需要额外计算。

3.2 中文分词的处理方案

RediSearch 默认的分词器对中文支持不太好，它会把连续的中文字符当成一个整体，导致搜索"蓝牙耳机"时匹配不到"无线蓝牙耳机"。解决这个问题有两种方案。

第一种是使用 RediSearch 内置的中文分词支持。从 2.4 版本开始，RediSearch 支持通过LANGUAGE参数指定中文，但效果一般。更好的方式是使用FT.CREATE时的STOPWORDS和自定义分词器。

第二种是使用第三方中文分词模块，比如 redisearch-chinese。这个模块集成了 jieba 分词，效果比较好。安装方式和 RediSearch 类似，编译成 .so 文件后加载即可。

如果不想引入额外模块，还有一个折中方案：在写入数据之前，先在应用层做好分词，把分词结果用空格拼接后存入一个额外的字段，然后对这个字段建 TEXT 索引。比如"无线蓝牙耳机"处理成"无线 蓝牙 耳机"，这样 RediSearch 的默认分词器就能正常工作了。

import jieba def preprocess_text(text): words = jieba.cut(text) return " ".join(words) # 写入时 title_segmented = preprocess_text("无线蓝牙耳机") redis.hset("product:1", mapping={ "title": "无线蓝牙耳机", "title_seg": title_segmented })

这个方案的好处是不依赖额外模块，缺点是增加了应用层的处理逻辑，而且分词结果会占用额外内存。

3.3 索引创建的实际操作与参数说明

下面是一个完整的索引创建示例，包含了我们商品搜索场景的所有字段：

FT.CREATE product_idx ON HASH PREFIX 1 product: SCHEMA title TEXT WEIGHT 5.0 SORTABLE description TEXT WEIGHT 1.0 category TAG SEPARATOR "," brand TAG SEPARATOR "," price NUMERIC SORTABLE stock NUMERIC created_at NUMERIC SORTABLE location GEO STOPWORDS 0 LANGUAGE chinese

逐项解释一下参数：

ON HASH表示索引的数据源是 Redis 的哈希结构。PREFIX 1 product:表示只索引以product:开头的键。WEIGHT 5.0表示标题字段的权重是 5.0，在相关性打分时占更高比重。SORTABLE表示该字段支持排序。SEPARATOR ","用于 TAG 字段，表示多个标签用逗号分隔。STOPWORDS 0表示不使用停用词表，因为中文停用词处理比较麻烦，干脆关掉。LANGUAGE chinese指定中文分词。

创建完索引之后，可以用FT.INFO product_idx查看索引状态，包括文档数量、索引大小、字段信息等。

3.4 索引内存占用的估算与优化

RediSearch 的索引是放在内存里的，所以内存占用是一个必须考虑的问题。根据我的实测经验，索引内存占用大概是原始数据大小的 1.5 到 3 倍，具体取决于字段类型和数量。

TEXT 字段的索引占用最大，因为需要存储倒排索引、词频、位置信息等。TAG 字段占用较小，NUMERIC 字段占用最小。如果内存紧张，可以考虑以下优化手段：

第一，只对必要的字段建索引。比如商品详情页的长描述，如果搜索时不需要匹配，就不要建 TEXT 索引。

第二，使用NOINDEX参数。有些字段只需要存储不需要索引，可以加上NOINDEX，这样 RediSearch 只存储不建索引，节省内存。

第三，调整MAXEXPANSIONS参数。这个参数控制前缀查询时最多扩展多少个词项，值越小内存占用越少，但可能影响召回率。

第四，定期清理过期数据。RediSearch 不会自动删除过期文档，需要在应用层做清理，或者用FT.DROPINDEX重建索引。

4. 查询实战：从简单搜索到复杂组合条件

4.1 基础全文搜索的写法与效果

最简单的查询就是直接传关键词：

FT.SEARCH product_idx "蓝牙耳机"

这会返回所有在 title 或 description 中包含"蓝牙"或"耳机"的文档，按相关性打分排序。默认返回前 10 条。

如果要分页，可以加LIMIT参数：

FT.SEARCH product_idx "蓝牙耳机" LIMIT 0 20

如果要指定返回哪些字段，用RETURN参数：

FT.SEARCH product_idx "蓝牙耳机" RETURN 3 title price category

这里有个细节要注意：RediSearch 默认会对查询词做 OR 匹配，也就是包含任意一个词就会返回。如果要 AND 匹配，需要显式指定：

FT.SEARCH product_idx "蓝牙 耳机"

实际上 RediSearch 的默认行为是：多个词之间是 AND 关系，但每个词内部会做前缀匹配和模糊匹配。这个行为和 ES 的match查询类似，但更激进一些。

4.2 组合过滤条件的实现方式

实际业务中，搜索往往不是单纯的关键词匹配，而是关键词加多个过滤条件。RediSearch 支持在查询中嵌入过滤表达式：

FT.SEARCH product_idx "耳机 @category:{数码} @price:[100 500] @stock:[1 +inf]" SORTBY price ASC LIMIT 0 20

这个查询的意思是：搜索包含"耳机"的文档，同时满足分类是"数码"、价格在 100 到 500 之间、库存大于 0。结果按价格升序排列。

过滤表达式的语法规则如下：

• TAG 字段用@field:{value1|value2}，多个值用|分隔
• NUMERIC 字段用@field:[min max]，+inf和-inf表示正负无穷
• 多个条件之间用空格分隔，表示 AND 关系
• 如果要 OR 关系，用|连接，比如@category:{数码|家电}

这里有个性能上的注意点：过滤条件放在查询字符串里和放在FILTER参数里，执行计划是不一样的。放在查询字符串里，RediSearch 会先做全文匹配再做过滤；放在FILTER参数里，会先做过滤再做全文匹配。哪种更快取决于数据分布，一般来说，过滤后结果集小的场景，用FILTER参数更快。

4.3 排序、分页与聚合统计

排序方面，RediSearch 支持按 NUMERIC 和 TEXT 字段排序，但前提是字段建索引时加了SORTABLE。排序语法：

FT.SEARCH product_idx "*" SORTBY price DESC LIMIT 0 10

*表示匹配所有文档，相当于全量查询。这种查询在数据量大时要注意，虽然 RediSearch 很快，但全量扫描仍然会消耗资源。

聚合统计是 RediSearch 比较强大的功能，类似 ES 的 aggregation。比如要统计每个分类下的商品数量和平均价格：

FT.AGGREGATE product_idx "*" GROUPBY 1 @category REDUCE COUNT 0 AS count REDUCE AVG 1 @price AS avg_price SORTBY 2 @count DESC

这个功能在商品筛选页的"分类计数"场景中很有用，可以一次性拿到所有分类的商品数量，不需要额外查询。

4.4 模糊搜索与拼写纠错

RediSearch 支持模糊搜索，通过在词后面加%来实现。比如：

FT.SEARCH product_idx "%蓝牙%"

这会匹配所有与"蓝牙"编辑距离在 1 以内的词。编辑距离可以通过%的数量来控制，%%表示距离 2，以此类推。

拼写纠错方面，RediSearch 提供了FT.SPELLCHECK命令：

FT.SPELLCHECK product_idx "蓝呀耳机"

它会返回建议的正确拼写。这个功能在用户输入错误时很有用，可以提升搜索体验。

不过要注意，模糊搜索和拼写纠错的性能开销比精确匹配大，因为需要遍历更多的词项。在高并发场景下要谨慎使用，或者限制使用频率。

5. 性能调优：把查询延迟压到极致

5.1 内存配置与淘汰策略

RediSearch 的性能高度依赖内存。如果内存不足，Redis 会触发淘汰策略，可能导致索引数据被驱逐，查询结果不完整。所以生产环境一定要配置好maxmemory和maxmemory-policy。

我的建议是：maxmemory设置为物理内存的 70% 到 80%，留出足够空间给操作系统和其他进程。maxmemory-policy设置为noeviction，因为搜索数据被淘汰的代价太高，宁可写入失败也不能让索引不完整。

如果内存实在不够，可以考虑分片。RediSearch 支持集群模式，可以把索引分散到多个节点上。但集群模式下的查询会涉及跨节点协调，延迟会比单节点高一些。

5.2 查询优化：减少不必要的字段扫描

查询优化的核心原则是：尽量缩小扫描范围。具体手段包括：

第一，用FILTER参数代替查询字符串中的过滤条件，让 RediSearch 先做过滤再做全文匹配。

第二，避免使用*全量查询，尽量带上过滤条件。

第三，对于只需要计数的场景，用LIMIT 0 0只返回总数，不返回文档内容：

FT.SEARCH product_idx "耳机" LIMIT 0 0

第四，合理使用RETURN参数，只返回需要的字段，减少网络传输和序列化开销。

第五，对于高频查询，可以考虑用 Redis 的缓存机制做二级缓存，把查询结果缓存起来，设置较短的过期时间。

5.3 索引重建与增量更新的平衡

RediSearch 的索引是实时更新的，插入或修改文档后，索引会立即更新。这个特性很方便，但在大批量写入时会影响查询性能。因为每次写入都要更新倒排索引，这是一个相对耗时的操作。

如果遇到大批量数据导入的场景，可以考虑以下策略：

第一，在低峰期做批量导入，避免影响在线查询。

第二，使用FT.CREATE的TEMPORARY参数创建临时索引，导入完成后再切换。

第三，如果数据量特别大，可以考虑先写入 Redis 但不建索引，等数据稳定后再用FT.CREATE一次性建索引。RediSearch 在创建索引时会扫描已有的键，这个过程比逐条更新索引快得多。

5.4 监控指标与告警设置

生产环境一定要做好监控。RediSearch 提供了一些关键指标，可以通过FT.INFO命令查看：

除了FT.INFO，还可以用 Redis 的INFO命令查看整体内存和 CPU 使用情况。建议设置告警：内存使用超过 80% 时告警，查询延迟 P99 超过 100ms 时告警，索引大小增长异常时告警。

6. 踩坑记录：那些文档里没写的问题

6.1 中文搜索的坑与解决方案

前面提到过中文分词的问题，这里再补充几个实际踩过的坑。

第一个坑是LANGUAGE chinese参数并不是所有版本都支持。我在一个 2.2 版本的 RediSearch 上试过，设置了这个参数但没生效，中文搜索还是有问题。后来升级到 2.4 版本才正常。所以如果中文搜索效果不对，先检查版本。

第二个坑是 TAG 字段的中文值。TAG 字段是精确匹配，不需要分词，但如果值里面有空格或特殊字符，需要用引号包裹，否则会被截断。比如@category:{数码 产品}会被解析成两个标签，正确的写法是@category:{"数码 产品"}。

第三个坑是中文标点符号。RediSearch 的分词器会把中文标点当成分隔符，导致"蓝牙，耳机"被分成"蓝牙"和"耳机"两个词。这个行为大多数时候是符合预期的，但有时候用户输入的标点会影响匹配结果。解决方案是在应用层做预处理，把中文标点替换成空格。

6.2 索引字段类型选错导致的性能问题

我犯过一个错误：把商品 ID 字段建成了 TEXT 类型。结果索引大小暴涨，因为每个 ID 都被分词成了多个词项。后来改成 TAG 类型，索引大小直接降了 40%。

还有一个类似的错误：把价格字段建成了 TEXT 类型。价格是数值，应该用 NUMERIC 类型，这样既支持范围查询又支持排序，而且索引占用小。用 TEXT 类型的话，范围查询和排序都没法做，只能精确匹配。

所以字段类型的选择一定要根据实际查询需求来定。判断标准很简单：需要全文搜索的用 TEXT，需要精确匹配的用 TAG，需要范围查询和排序的用 NUMERIC。

6.3 集群模式下的查询限制

RediSearch 在集群模式下有一些限制，我在实际使用中遇到过几个。

第一，FT.AGGREGATE在集群模式下的行为和非集群模式不一样。非集群模式下可以跨所有文档做聚合，集群模式下只能在单个分片内聚合，需要应用层做二次合并。

第二，FT.SPELLCHECK在集群模式下不支持。

第三，跨分片的排序和分页需要协调节点做额外处理，延迟会比单节点高。

如果业务对聚合和排序要求高，建议用单节点大内存方案，而不是集群。单节点 64G 内存能扛住千万级数据的搜索场景，比集群更简单也更稳定。

6.4 数据一致性与持久化问题

RediSearch 的索引数据是存在内存里的，虽然 Redis 有 RDB 和 AOF 持久化机制，但索引的重建需要时间。如果 Redis 重启，索引需要从持久化文件中恢复，这个过程可能比较慢。

我的建议是：生产环境一定要开启 AOF 持久化，并且设置appendfsync everysec。这样即使宕机，最多丢失 1 秒的数据。同时，应用层要做好降级方案，Redis 不可用时能切换到数据库查询。

另外，RediSearch 的索引和 Redis 的键是绑定的。如果键过期或被删除，索引也会相应更新。但这个过程不是原子的，在高并发下可能出现短暂的不一致。如果业务对一致性要求高，需要在应用层做补偿。

7. 和 ElasticSearch 的选型对比：什么场景该用哪个

7.1 性能、成本、运维三个维度的对比

经过这段时间的实践，我对两者的差异有了比较清晰的认识。下面从三个维度做一个对比：

从表格可以看出，RediSearch 的优势在于性能和运维简单，劣势在于全文搜索和聚合分析能力不如 ES，生态也没那么丰富。

7.2 我的选型决策框架

基于实际经验，我总结了一个简单的选型框架：

选 RediSearch 的场景：数据量在千万级以内、查询以关键词加过滤为主、对延迟敏感、团队没有专职的 ES 运维、已经在用 Redis 不想引入新组件。

选 ElasticSearch 的场景：数据量在亿级以上、需要复杂的聚合分析和报表、需要全文搜索的高级功能（如高亮、同义词、多语言分词）、团队有 ES 运维经验、对延迟要求不那么苛刻。

还有一个中间方案：用 RediSearch 做在线搜索，用 ES 做离线分析和报表。两者各取所长，通过数据同步保持一致。这个方案适合数据量大且分析需求复杂的场景。

7.3 迁移成本和实际收益的权衡

从 ES 迁移到 RediSearch 的成本主要在这几个方面：查询语法需要重写、索引设计需要调整、应用层的代码需要改造、监控和告警需要重新配置。

收益方面，最明显的是延迟降低和吞吐量提升，其次是运维成本下降。我们迁移之后，服务器数量从 3 台 ES 节点减少到 1 台 Redis 节点，每月成本降低了大概 60%。查询延迟从平均 300ms 降到 20ms，用户体验提升明显。

但也不是所有场景都适合迁移。如果业务重度依赖 ES 的聚合分析和复杂查询，迁移的收益可能抵不上改造成本。所以做决策之前，一定要先评估自己的查询模式和数据特征。

8. 一些实用的运维经验

8.1 日常巡检要看哪些指标

日常运维中，我每天会看这几个指标：内存使用率、查询延迟 P99、慢查询数量、索引大小增长趋势、连接数。

内存使用率是最关键的，超过 80% 就要警惕。查询延迟 P99 反映了长尾情况，如果突然升高，可能是数据量增长或者有慢查询。慢查询可以通过 Redis 的SLOWLOG命令查看。索引大小增长趋势可以帮助预判内存需求。连接数反映了并发压力。

8.2 备份与恢复的实操步骤

RediSearch 的备份和 Redis 的备份是一样的，用BGSAVE生成 RDB 文件，或者用 AOF 文件。恢复时把 RDB 或 AOF 文件放到数据目录，重启 Redis 即可。

但要注意，索引的重建需要时间。千万级数据的索引重建可能需要几分钟到十几分钟。所以恢复过程中，应用层要有降级方案，不能直接不可用。

另外，建议定期做恢复演练，确保备份文件是可用的。我遇到过备份文件损坏的情况，如果没有演练，真出事的时候就麻烦了。

8.3 版本升级的注意事项

RediSearch 的版本升级需要谨慎。不同版本之间的索引格式可能不兼容，升级后可能需要重建索引。

升级步骤建议：先在测试环境验证、备份生产数据、在低峰期执行升级、升级后验证功能和性能、观察一段时间再确认没问题。

还有一个细节：RediSearch 的版本和 Redis 的版本有对应关系，升级 RediSearch 可能也需要升级 Redis。这个要提前规划好。

8.4 常见故障的排查思路

最后分享几个常见故障的排查思路。

查询变慢：先看内存使用率，再看慢查询日志，然后检查是否有大批量写入。如果内存不足，考虑扩容或清理数据。

索引不更新：检查 Redis 的键是否正常写入，检查索引的 PREFIX 是否匹配，检查是否有错误日志。

内存暴涨：检查是否有大量新数据写入，检查索引字段类型是否合理，检查是否有大 key。

连接超时：检查连接数是否达到上限，检查网络是否正常，检查 Redis 是否在阻塞操作。

这些排查思路都是我在实际运维中总结出来的，希望能帮到遇到类似问题的朋友。RediSearch 虽然好用，但也不是银弹，理解它的原理和边界，才能用好它。