Redis FT Search与普通Redis字符串键缓存的差异及适用场景

核心差异 #

• 数据模型不同：普通缓存是纯键值对结构，值可以是字符串、哈希、列表等Redis原生数据类型，所有操作都围绕完整键展开；FT Search是把数据结构化存储为文档（类似MongoDB的文档），每个文档有多个字段，查询可以基于任意字段。
• 查询能力天差地别：普通缓存只能做键的精确匹配，或者低效的前缀/后缀模糊匹配，只有键查询是O(1)复杂度；FT Search支持全文检索、多字段组合查询、数值范围筛选、排序、聚合等，能满足复杂的检索需求，但查询复杂度取决于索引设计。
• 存储与维护成本不同：普通缓存结构简单，几乎没有额外存储开销；FT Search需要为文档字段构建倒排索引，会占用更多内存，而且需要维护索引的更新（比如文档修改后同步更新索引）。
• 上手难度不同：在Spring Boot里用普通缓存，加个@Cacheable注解就能快速实现缓存逻辑，几乎不需要额外学习；FT Search得先定义索引结构、映射数据库表字段，代码里还要写检索逻辑，学习和配置成本更高。

适用场景 #

普通缓存更适合这些场景 #

• 热点单条数据快速读取：比如用户基本信息、商品详情、系统配置参数，这些数据用唯一ID就能直接定位，不需要复杂查询。
• 会话与状态缓存：存储用户会话ID对应的会话数据、接口请求的临时状态，只需要通过唯一标识查询。
• 接口结果缓存：缓存分页列表、统计接口的返回结果，用请求参数拼接成键来缓存，避免重复计算或查询数据库。

Redis FT Search更适合这些场景 #

• 多条件组合检索：比如电商的商品筛选，要按关键词、价格区间、品牌、销量排序等多个条件查询；或者后台管理系统的用户筛选，按注册时间、地区、角色组合查询。
• 全文搜索需求：比如文章内容搜索、商品描述关键词检索，需要对文本内容做分词匹配。
• 轻量级检索替代方案：当数据库的检索性能跟不上，又不想引入Elasticsearch这类重型引擎时，用FT Search处理中小规模的结构化+全文检索需求，架构更轻量。

内容的提问来源于stack exchange，提问作者Youssef Gamal