如果你曾经为一个很简单的需求发过愁——想在 Redis 里存一个 JSON 对象按字段查一查、改一改却发现在原版 Redis 里只能把整个 JSON 序列化成字符串塞进去要改其中一个字段还得整串读出来、反序列化、改完再写回去并发一高就提心吊胆。我当时就是被这个痛点逼着去了解 Redis Stack 的。简单说Redis Stack 就是把官方维护的几个扩展模块和 Redis 本身打包在一起装好之后你立刻能用的不止是 SET/GET还有 JSON、Search、Time Series、Bloom 这些数据类型和能力。这篇文章是我在入门系列里整理的第六篇目标读者和我当时一样已经知道 Redis 基本用法但不满足于只拿它当缓存还想让它承担更多活的开发者。我会从安装、核心模块、组合实战到容易踩的坑按我实际摸过的顺序写下来。1. 先别急着装Redis Stack 和原版 Redis 到底差在哪1.1 它不是新数据库而是“官方打包发行版”很多人第一次听到 Redis Stack容易误以为这是一个全新的数据库或者以为它是个测试版其实都不是。它更像是“发行版”的概念底层依然是 Redis 本身数据结构和命令完全兼容只是官方把几个经过长期验证的模块和 Redis 二进制打包在一起发布让你不用自己去编译模块、配模块、担心模块和内核版本不匹配。早期这些模块是独立的比如 RedisJSON、RediSearch、RedisTimeSeries、RedisBloom你要自己下载、编译、然后在 redis.conf 里通过 loadmodule 加载。听起来不复杂但真做起来挺烦的模块有各自的版本和 Redis 版本有兼容矩阵升级 Redis 的时候模块可能编译不过生产环境里还得给每个节点重复操作一遍。Redis Stack 就是把这一坨事情收敛成“一个安装包搞定”。另外早期 Redis Stack 还有自己独立的版本号比如 6.2.x后来官方把版本号直接和 Redis 对齐了目前你看到 7.2 的 Stack 就是基于 Redis 7.2 的这样理解起来更简单。1.2 装上以后你会多出哪几类命令模块不是藏起来的它直接映射成新命令。你装完 Redis Stack在 redis-cli 里敲 COMMAND COUNT 会发现命令数量比原版多出几百条。我按用途给你分一下JSON 相关JSON.SET、JSON.GET、JSON.ARRAPPEND、JSON.OBJKEYS 等专门操作 JSON 文档。搜索相关FT.CREATE、FT.SEARCH、FT.AGGREGATE、FT.INFO支持全文检索、字段过滤、聚合、排序7.2 以后还带了向量相似度搜索。时序相关TS.CREATE、TS.ADD、TS.RANGE、TS.CREATERULE支持时序数据的写入、范围查询、聚合降采样。概率相关BF.ADD、BF.EXISTS、BF.RESERVE也就是布隆过滤器还有 Cuckoo Filter、Count-Min Sketch、Top-K 这些概率数据结构。早期版本里还打包过一个 Graph 模块后来官方决定停掉这块的维护并把它从默认集合里摘了出去。所以现在你看到文档里的 Redis Stack 模块集合就是 JSON、Search、Time Series、Bloom 四个为主。这个变化其实挺能说明问题的不是模块越多越好维护不住的东西就会被砍掉你用的时候也别指望长期依赖某个冷门模块。1.3 大量教程不提的版本合并细节再强调一个容易忽略的点Redis Stack 是“打包”不是“改写”。也就是说你原来部署的原版 Redis 数据文件RDB/AOF理论上可以迁移到 Redis Stack因为核心存储引擎还是同一个反过来也一样。但如果你用了模块产生的新数据类型比如 JSON 类型、索引结构那旧版原版 Redis 是读不了的。还有一点Stack 安装包默认会启用全部模块。如果你只打算用 JSON搜索模块也照样会加载会占一点内存和启动时间。这一点在 Docker 容器、小内存 VPS 上尤其要注意后面我会单独讲怎么按需启用。总之对“Redis Stack 是什么”有个准确认知后面不管装还是用思路都会清晰很多。2. 一条命令跑起来安装选择和第一轮实测验证2.1 最省事的 Docker 方式与端口细节我自己最先试的就是 Docker因为不需要在当前系统里折腾编译依赖。官方提供了 redis-stack 和 redis-stack-server 两个镜像区别很简单带 Server 的是精简服务端没有图形界面不带 Server 的额外包含 RedisInsight 图形管理工具。日常学习和开发直接跑完整的镜像更方便docker run -d --name redis-stack \ -p 6379:6379 \ -p 8001:8001 \ redis/redis-stack:latest这里 6379 是 Redis 默认端口8001 是 RedisInsight 网页管理工具的端口。有一点我得提醒如果你是在自己电脑上跑建议把 8001 绑定到本机别直接暴露到局域网RedisInsight 本身功能很全暴露出去等于把数据管理入口公开了。更好的写法是docker run -d --name redis-stack \ -p 127.0.0.1:6379:6379 \ -p 127.0.0.1:8001:8001 \ redis/redis-stack:latest启动后可以用 docker logs 看启动日志等出现 Ready to accept connections 就可以连了。2.2 在 Linux 上直接装二进制不用 Docker 的场景比如你有一台长期运行的测试服务器不想为 Redis 额外引入容器层那可以直接从官方提供的中文文档界面找到对应系统的下载包。以 Ubuntu 这种 Debian 系为例它支持通过 apt 仓库安装装完之后会有 redis-stack-server 这个可执行文件。如果下载的是 tar.gz 包解压后目录里有 bin/redis-stack-server直接运行即可./bin/redis-stack-server --daemonize yes它会自己去加载配置目录里的模块不需要手工 loadmodule。要注意的是Stack 的默认配置里持久化是打开的如果你只是临时测试不想写盘启动时记得加一个空配置或者把 save 参数改成 否则测试完一堆 dump.rdb 堆在目录里。2.3 装完之后先做这几个检查装完别急着写业务代码先确认模块真的加载了。在 redis-cli 里执行下面三条基本就能看出状态redis-cli MODULE LIST redis-cli COMMAND COUNT redis-cli INFO serverMODULE LIST 会列出已经加载的模块名正常情况下你能看到 json、search、timeseries、bf 这些。COMMAND COUNT 如果比原版多很多说明新命令已经注册进去了。也可以直接试一条最简单的 JSON 命令比如 JSON.SET test $ hello 然后 JSON.GET test能正常返回说明 JSON 模块可用。我遇到过一种坑某些第三方构建的“Redis Stack”镜像其实只是装了原版 Redis 再塞进去部分模块模块不全所以检查这一步一定不要省。3. 四个高频模块逐个拆解JSON、Search、Time Series、Bloom3.1 RedisJSON让“更新缓存里的一个字段”不再心惊胆战先说我最常用的 JSON 模块。原版 Redis 里存 JSON 对象普遍做法是 SET key {user:{name:张三,age:30}}整串存取。问题在于你只是想改 age 字段也得先把整串 GET 回来在应用里解析修改再 SET 回去。万一这个过程中另一个请求也在改同一个 key就会出现“后写覆盖先写”的丢失更新问题。RedisJSON 解决的是这个根子上的问题它把 JSON 文档当成一种原生数据类型存储允许你直接对文档内部的路径做原子操作。最常用的几个命令JSON.SET user:1001 $ {name:张三,age:30,skills:[Redis,Docker]} JSON.GET user:1001 $.name JSON.SET user:1001 $.age 31 JSON.ARRAPPEND user:1001 $.skills Go第二个命令里的 $.name 是 JSONPath 语法$ 表示根节点.name 表示取根节点下的 name 字段。这比 XPath 简单但写法上也有不少讲究。比如想取 skills 数组的第一个元素可以用 $.skills[0]想判断字段是否存在可以用 JSON.TYPE user:1001 $.name。文档结构越复杂越能体现出它比整串读写的优势。我实际感受是会话信息、用户资料、配置快照这类“半结构化、经常局部修改”的场景从原版迁移到 RedisJSON 后并发更新问题基本消失代码里也不需要再做序列化反序列化那一套了。3.2 RediSearch缓存层顺手把全文检索也干了如果不了解 Redis Stack你大概率不会把“搜索引擎”和“缓存”放在一个进程里。但 RediSearch 恰恰做了这件事。它支持哈希和 JSON 两种数据结构建索引支持全文检索、数值范围过滤、排序、聚合、甚至向量相似度搜索。我最早用它是在一个商品服务里给商品名称和描述做站内搜索效果确实比让我自己遍历所有商品再内存筛选好太多。建索引的逻辑是先告诉它哪些前缀的 key 要进索引再告诉它哪些字段按什么类型处理。比如商品 key 都是以 product: 开头里面有 name 和 price那就这么建FT.CREATE idx:product ON JSON PREFIX 1 product: \ SCHEMA $.name AS name TEXT \ $.price AS price NUMERIC然后搜“机械键盘”并按照价格从低到高排序FT.SEARCH idx:product name:机械键盘 SORTBY price ASC LIMIT 0 10FT.SEARCH 返回的结果会把整条文档带回来省去你查完索引再回 Redis 取数据的第二步。这一点在业务代码里非常舒服。RediSearch 的聚合是另一个亮点比如你想统计每个品牌下面有多少商品、平均价格多少一条 FT.AGGREGATE 就能出结果不需要把几万条商品拉到应用层 reduce。不过别因为功能多就贪心建索引本身要占内存字段越多索引越大索引创建的瞬间还可能阻塞主线程后面性能部分我会展开讲。3.3 RedisTimeSeries时序数据入库前先压缩Time Series 模块解决的是监控指标、传感器数据这类不停追加时间戳数值的场景。如果直接往 Redis 里写几百万个字符串 key内存开销大查询也不方便。Time Series 模块提供专门的数据结构每条记录是“时间戳 值”底层按块存储还支持自动压缩和聚合规则。基本用法TS.CREATE metric:cpu_usage RETENTION 86400000 TS.ADD metric:cpu_usage 1718000000000 42.5 TS.RANGE metric:cpu_usage 1718000000000 1718003600000 AGGREGATION avg 60000第一条创建一条保留 24 小时的时序超时的数据自动清理不需要你再写定时任务扫 key。第三条是范围查询按每 60 秒一个桶做平均值聚合非常适合做监控图表的数据源。我最喜欢的是 TS.CREATERULE它能在写入的同时自动把原始数据聚合成更粗粒度的另一条时序比如把 1 秒粒度聚合成 1 分钟粒度这样查询 30 天趋势的时候不用对几百万个点做聚合计算。这对监控系统来说几乎是刚需。要注意的是时序数据的 key 数量一多Docker 跑着没设内存上限很容易把宿主机内存吃爆最好给每个时序设置合理的 RETENTION宁可后面查不到太久远的数据也别让它无限增长。3.4 RedisBloom极低内存挡住不存在的 keyBloom 模块跟前面几个不同它不存储原始数据只维护一个概率结构用来回答“某个 key 肯定不存在或可能存在”。最典型的场景是防缓存穿透很多恶意请求会拿一串根本不存在的 ID 来打你的缓存接口如果每个请求都穿透到数据库数据库分分钟被拖垮。用法非常简单BF.RESERVE bf:product 0.001 100000 BF.ADD bf:product 1001 BF.EXISTS bf:product 1001 BF.EXISTS bf:product 99999第一行的两个参数分别是期望误判率0.1%和预计要加入的元素数量10 万个。这两个参数会直接决定底层位数组的大小。有一个近似公式可以估算内存位数组长度约等于-n * ln(p) / (ln 2)^2n 是元素数量p 是误判率。按 10 万个元素、0.1% 误判率算大概不到 200KB非常省。如果只加不涨误判率又会慢慢升高所以调参要给自己留余量。另外 Bloom 模块里还有 Cuckoo Filter支持删除元素布隆过滤器本身不支持删除所以如果你有频繁删除的需求可以用 CF 系列命令。但大多数接口防穿透场景都是只增不减BF 就够了。4. 组合起来用一次商品详情缓存加搜索引擎加防穿透4.1 场景设定和需要解决的问题单个模块的用法看明白之后最有价值的其实是把它们组合起来。我拿一个典型的电商商品服务来举例这个服务要解决四个问题商品详情缓存、商品名称搜索、按价格筛选、以及防止不存在的商品 ID 打爆数据库。原版 Redis 的做法是详情用字符串缓存序列化后的商品 JSON搜索要么靠数据库 LIKE 要么靠外部搜索引擎防穿透要么用空值缓存要么自己维护一个布隆过滤器。每一样都能凑合用但凑起来很零散。用 Redis Stack一个进程全搞定而且都是原生命令级操作不需要额外中间件。4.2 用 JSON 模块做详情缓存与局部更新首先把商品详情存成 JSON 格式JSON.SET product:1001 $ {id:1001,name:机械键盘,brand:keychron,price:399,tags:[外设,无线]}然后用 JSON 命令做局部更新。比如用户下单后库存减一不需要整串更新只需JSON.NUMINCRBY product:1001 $.stock -1JSON.NUMINCRBY 是对数值类型字段做增减的原子操作比“读出来改后写回”安全得多。这个场景如果只用原版 Redis你多半会引入 Lua 脚本来保证原子性现在用 JSON 模块原生命令省了一层事。4.3 用 Search 模块做标题搜索与价格筛选商品数据在 JSON 里搜索模块可以直接对它建索引不需要另一份冗余结构。索引建好后即便后面新增的 product: 开头的 key也会自动进入索引前提是它在 PREFIX 1 product: 指定的前缀范围内。FT.CREATE idx:product ON JSON PREFIX 1 product: \ SCHEMA $.name AS name TEXT \ $.brand AS brand TAG \ $.price AS price NUMERIC \ $.tags[*] AS tags TAG这里有一个细节品牌用 TAG 类型而不是 TEXT因为品牌适合精确匹配和分类过滤不适合分词。TAG 类型查询要用大括号包起来比如FT.SEARCH idx:product brand:{keychron} price:[300 500] LIMIT 0 10这句话的意思是品牌是 keychron、价格在 300 到 500 之间的商品取前 10 条。TEXT 和 TAG 用错是新手最容易犯的错误搞错了搜出来的结果要么是 0要么把不该分词的词拆碎了。记住一个判断口诀需要分词模糊搜用 TEXT需要精确分类过滤用 TAG。4.4 用 Bloom 模块挡掉恶意扫描商品 ID 通常是自增数字恶意请求很容易连续遍历不存在的 ID。做法是在查询流程前面加一道布隆过滤器请求进来先 BF.EXISTS bf:product {id}如果返回 0说明这个 ID 大概率不存在直接返回空不打数据库如果返回 1说明可能存在继续查缓存或数据库数据库中查到后把真实存在的 ID 加到布隆过滤器里这里要注意布隆过滤器是存在判断不是缓存所以不会因为 TTL 过期导致数据丢失。初始化参数方面我建议按业务三年内的商品总量再乘 2 来设置容量因为加元素不加容量会让误判率上升。误判率我一般设 0.001也就是千分之一足够挡住绝大多数穿透请求。4.5 补上 TTL、命名与数据一致性方案组合方案里最容易被忽略的是命名规范和失效策略。我建议所有 key 统一用业务前缀加冒号分层比如 product:1001、idx:product、bf:product这样后续用 SCAN 做统计也好分类。再一个就是 TTL。布隆过滤器不能设置 TTL因为删除 key 相当于重建会把所有已存在的 ID 判定消失。但商品详情 JSON 可以给一个短 TTL比如 30 分钟缓存自动过期后再从数据库加载。这里就有一个一致性问题如果数据库里的商品改了缓存 TTL 没到怎么办比较粗暴也实用的做法是双写修改数据库成功后顺便调 JSON.SET 覆盖缓存如果事务失败就 DEL product:1001 让缓存失效。加上 TTL 兜底基本能接受。整个组合方案跑下来的感觉是架构上少了一堆外部依赖运维上只需要盯一个 Redis 实例业务代码也不用维护两套不同中间件的客户端。对于中小型服务这种“一个进程解决缓存、搜索、防穿透”的设计性价比确实很高。5. 那些看不见的内存和协议门槛踩过才懂5.1 RESP2 和 RESP3 的客户端兼容问题Redis 从 6.0 开始支持 RESP3 协议Redis Stack 的模块大量依赖响应类型更丰富的 RESP3。RESP2 时代返回的很多是字符串数组RESP3 能返回 Map、Double 等结构化类型。问题是如果你的客户端库太老默认协商的是 RESP2会发现部分模块命令返回的数据格式诡异。我遇到过的情况是用某个老版本客户端去执行 FT.AGGREGATE结果解析出来的结果全是字符串拼接得不到结构化字段。排查了半天最后发现是客户端桶不支持 RESP3。解决办法很直接升级客户端库到支持 RESP3 的版本比如较新的 redis-py、Jedis、node-redis。如果你的客户端在连接参数里能设置 protocol3手动声明。实在不想升级就还在 RESP2 模式下跑但最好别把聚合这种复杂响应类型的命令用在生产代码里。这个问题网上资料少也不容易想到但我身边的同事真踩过。所以装完 Stack先查一查你用的客户端库版本和协议支持情况能省下后面很多排查时间。5.2 索引内存比数据本身还大怎么预估RediSearch 建索引的时候索引结构会单独占用内存。字段越多的类型索引越大特别是 TEXT 类型要分词分词后每个词都要建倒排表内存开销很可观。可能你整个商品 JSON 原始数据只有 100MB但索引内存反而到了 300MB。这个现象在 INFO memory 里能看出来used_memory 会比你预想高不少。要精确区分数据内存和索引内存可以用 MODULE 的命令或者查看内存分析工具。但更务实的做法是在设计阶段就控制只给需要搜索的字段建索引别把什么备注、日志字段统统塞进 SCHEMA。TEXT 字段能不建全文就不要建没搜索需求的字段用 TAG 或者直接不索引。考虑给索引设置上限比如 FT.CONFIG 调整内存限制超过阈值索引不再写入避免整个 Redis OOM。我在测试环境碰到过一次商品详情就几千条建了 6 个字段的索引其中两个大字段用了 TEXT结果内存直接比无索引时大了 4 倍。后来把那两个字段改成 TAG或者去掉索引内存立刻降下来。所以索引不是“建了就完事”它是要用内存换查询速度的你得知道这笔账怎么算。5.3 阻塞与持久化的取舍大对象操作要谨慎Redis 单线程执行命令Redis Stack 的模块命令也不例外。这就意味着一条很大的 JSON 写入、一次很大的 FT.CREATE、一次复杂的聚合查询都会阻塞其他命令的执行导致整个实例的延迟抖动。我实测过往 RedisJSON 里写入一个几 MB 的 JSON 文档解析和构建内部结构花了几十毫秒这几十毫秒内其他读写命令全部排队。所以对于大 JSON 写入要么在业务低峰期做要么拆分成小块写入。Search 模块建索引也是一样第一次 FT.CREATE 如果覆盖几百万个 key最好是凌晨跑或者分批用 PREFIX 范围控制。持久化方面还有一个容易忽略的点模块产生的数据结构和索引在 RDB 持久化和 AOF 重写时都会被序列化。不同模块有自己的序列化格式所以 Redis Stack 的 RDB 文件只能由同样模块版本兼容的实例加载。升级的时候如果只升级 Redis 版本而模块版本不匹配可能直接加载失败。我的建议是升级前先备份最好先在一个临时实例上恢复一下 RDB 验证能不能起来再滚到生产。6. 什么时候该选 Stack什么时候继续用原版6.1 适合接入的三种典型架构不是所有场景都该用 Redis Stack过早把模块全启用了反而多占内存。我梳理下来它特别适合这三类架构第一类是“缓存加搜索一体化”的业务。比如商品、文章、用户列表这类既要缓存又要检索的场景Stack 把缓存和搜索放一起省掉一个 Elasticsearch 或 Solr 的重型依赖。第二类是“高并发防穿透加”的接口层。电商、内容站、账务系统总会遇到扫 ID 的恶意流量Bloom 过滤器加缓存是一套标准方案Stack 内置之后不需要再单独引入其他服务。第三类是“监控和缓存共存”的运维场景。应用服务本身用 Redis 做缓存同时又要采集一些业务指标比如接口调用量、耗时分布Time Series 模块可以直接塞到同一个实例里不一定非要再搭一套时序数据库。6.2 集群模式和模块的兼容性现实要提醒的是Redis Stack 在单机、主从、哨兵模式下都比较好使但在 Redis Cluster 模式下有些模块的命令支持是受限的。搜索模块在集群环境下可以做分布式搜索但需要特殊的部署方式和配置JSON 模块在集群模式下的跨 slot 操作也会受限。这些坑文档里都有说明但很多人没仔细看导致搭好了集群才发现某个命令报错。我自己的体会是如果业务量还没到必须上集群的地步优先用单机配持久化省心得多如果真到了集群规模先把模块命令的集群兼容性表拉出来一个一个对照业务场景别等上线了再试错。对于新项目还有一个“反向选择”的思路先用原版 Redis 把基本缓存跑通确实遇到模块需求再迁移到 Stack迁移成本其实很低因为底层数据格式兼容。不用一开始就把所有模块都用上。6.3 我现在的选型心法和上手建议整理一下我的选型心法内存预算够、想省架构组件、团队愿意接受新命令Redis Stack 值得用反之如果只有几百 MB 内存、业务纯粹是 KV 缓存老老实实跑原版 Redis别为了“新功能”而扩容。如果你决定上手建议按这个顺序学先把 JSON 模块用熟因为它带来的收益最直观、风险最小接着玩 Search从最简单的 TAG 过滤开始再碰 TEXT 全文索引然后加 Bloom 防穿透最后在需要监控指标时再碰 Time Series。不要一上来四个模块一起上出了问题你都分不清是哪个模块引起的。最后分享一个小习惯我会在每次升级 Redis Stack 版本前跑一遍自己整理的“模块冒烟脚本”集中执行 JSON 写入、索引创建、时序写入、布隆判断这几类命令确认返回结果符合预期再动生产。版本升级这种事官方文档写得再清楚也顶不上自己亲手验证一遍来得踏实。
如果你曾经为一个很简单的需求发过愁——想在 Redis 里存一个 JSON 对象按字段查一查、改一改却发现在原版 Redis 里只能把整个 JSON 序列化成字符串塞进去要改其中一个字段还得整串读出来、反序列化、改完再写回去并发一高就提心吊胆。我当时就是被这个痛点逼着去了解 Redis Stack 的。简单说Redis Stack 就是把官方维护的几个扩展模块和 Redis 本身打包在一起装好之后你立刻能用的不止是 SET/GET还有 JSON、Search、Time Series、Bloom 这些数据类型和能力。这篇文章是我在入门系列里整理的第六篇目标读者和我当时一样已经知道 Redis 基本用法但不满足于只拿它当缓存还想让它承担更多活的开发者。我会从安装、核心模块、组合实战到容易踩的坑按我实际摸过的顺序写下来。1. 先别急着装Redis Stack 和原版 Redis 到底差在哪1.1 它不是新数据库而是“官方打包发行版”很多人第一次听到 Redis Stack容易误以为这是一个全新的数据库或者以为它是个测试版其实都不是。它更像是“发行版”的概念底层依然是 Redis 本身数据结构和命令完全兼容只是官方把几个经过长期验证的模块和 Redis 二进制打包在一起发布让你不用自己去编译模块、配模块、担心模块和内核版本不匹配。早期这些模块是独立的比如 RedisJSON、RediSearch、RedisTimeSeries、RedisBloom你要自己下载、编译、然后在 redis.conf 里通过 loadmodule 加载。听起来不复杂但真做起来挺烦的模块有各自的版本和 Redis 版本有兼容矩阵升级 Redis 的时候模块可能编译不过生产环境里还得给每个节点重复操作一遍。Redis Stack 就是把这一坨事情收敛成“一个安装包搞定”。另外早期 Redis Stack 还有自己独立的版本号比如 6.2.x后来官方把版本号直接和 Redis 对齐了目前你看到 7.2 的 Stack 就是基于 Redis 7.2 的这样理解起来更简单。1.2 装上以后你会多出哪几类命令模块不是藏起来的它直接映射成新命令。你装完 Redis Stack在 redis-cli 里敲 COMMAND COUNT 会发现命令数量比原版多出几百条。我按用途给你分一下JSON 相关JSON.SET、JSON.GET、JSON.ARRAPPEND、JSON.OBJKEYS 等专门操作 JSON 文档。搜索相关FT.CREATE、FT.SEARCH、FT.AGGREGATE、FT.INFO支持全文检索、字段过滤、聚合、排序7.2 以后还带了向量相似度搜索。时序相关TS.CREATE、TS.ADD、TS.RANGE、TS.CREATERULE支持时序数据的写入、范围查询、聚合降采样。概率相关BF.ADD、BF.EXISTS、BF.RESERVE也就是布隆过滤器还有 Cuckoo Filter、Count-Min Sketch、Top-K 这些概率数据结构。早期版本里还打包过一个 Graph 模块后来官方决定停掉这块的维护并把它从默认集合里摘了出去。所以现在你看到文档里的 Redis Stack 模块集合就是 JSON、Search、Time Series、Bloom 四个为主。这个变化其实挺能说明问题的不是模块越多越好维护不住的东西就会被砍掉你用的时候也别指望长期依赖某个冷门模块。1.3 大量教程不提的版本合并细节再强调一个容易忽略的点Redis Stack 是“打包”不是“改写”。也就是说你原来部署的原版 Redis 数据文件RDB/AOF理论上可以迁移到 Redis Stack因为核心存储引擎还是同一个反过来也一样。但如果你用了模块产生的新数据类型比如 JSON 类型、索引结构那旧版原版 Redis 是读不了的。还有一点Stack 安装包默认会启用全部模块。如果你只打算用 JSON搜索模块也照样会加载会占一点内存和启动时间。这一点在 Docker 容器、小内存 VPS 上尤其要注意后面我会单独讲怎么按需启用。总之对“Redis Stack 是什么”有个准确认知后面不管装还是用思路都会清晰很多。2. 一条命令跑起来安装选择和第一轮实测验证2.1 最省事的 Docker 方式与端口细节我自己最先试的就是 Docker因为不需要在当前系统里折腾编译依赖。官方提供了 redis-stack 和 redis-stack-server 两个镜像区别很简单带 Server 的是精简服务端没有图形界面不带 Server 的额外包含 RedisInsight 图形管理工具。日常学习和开发直接跑完整的镜像更方便docker run -d --name redis-stack \ -p 6379:6379 \ -p 8001:8001 \ redis/redis-stack:latest这里 6379 是 Redis 默认端口8001 是 RedisInsight 网页管理工具的端口。有一点我得提醒如果你是在自己电脑上跑建议把 8001 绑定到本机别直接暴露到局域网RedisInsight 本身功能很全暴露出去等于把数据管理入口公开了。更好的写法是docker run -d --name redis-stack \ -p 127.0.0.1:6379:6379 \ -p 127.0.0.1:8001:8001 \ redis/redis-stack:latest启动后可以用 docker logs 看启动日志等出现 Ready to accept connections 就可以连了。2.2 在 Linux 上直接装二进制不用 Docker 的场景比如你有一台长期运行的测试服务器不想为 Redis 额外引入容器层那可以直接从官方提供的中文文档界面找到对应系统的下载包。以 Ubuntu 这种 Debian 系为例它支持通过 apt 仓库安装装完之后会有 redis-stack-server 这个可执行文件。如果下载的是 tar.gz 包解压后目录里有 bin/redis-stack-server直接运行即可./bin/redis-stack-server --daemonize yes它会自己去加载配置目录里的模块不需要手工 loadmodule。要注意的是Stack 的默认配置里持久化是打开的如果你只是临时测试不想写盘启动时记得加一个空配置或者把 save 参数改成 否则测试完一堆 dump.rdb 堆在目录里。2.3 装完之后先做这几个检查装完别急着写业务代码先确认模块真的加载了。在 redis-cli 里执行下面三条基本就能看出状态redis-cli MODULE LIST redis-cli COMMAND COUNT redis-cli INFO serverMODULE LIST 会列出已经加载的模块名正常情况下你能看到 json、search、timeseries、bf 这些。COMMAND COUNT 如果比原版多很多说明新命令已经注册进去了。也可以直接试一条最简单的 JSON 命令比如 JSON.SET test $ hello 然后 JSON.GET test能正常返回说明 JSON 模块可用。我遇到过一种坑某些第三方构建的“Redis Stack”镜像其实只是装了原版 Redis 再塞进去部分模块模块不全所以检查这一步一定不要省。3. 四个高频模块逐个拆解JSON、Search、Time Series、Bloom3.1 RedisJSON让“更新缓存里的一个字段”不再心惊胆战先说我最常用的 JSON 模块。原版 Redis 里存 JSON 对象普遍做法是 SET key {user:{name:张三,age:30}}整串存取。问题在于你只是想改 age 字段也得先把整串 GET 回来在应用里解析修改再 SET 回去。万一这个过程中另一个请求也在改同一个 key就会出现“后写覆盖先写”的丢失更新问题。RedisJSON 解决的是这个根子上的问题它把 JSON 文档当成一种原生数据类型存储允许你直接对文档内部的路径做原子操作。最常用的几个命令JSON.SET user:1001 $ {name:张三,age:30,skills:[Redis,Docker]} JSON.GET user:1001 $.name JSON.SET user:1001 $.age 31 JSON.ARRAPPEND user:1001 $.skills Go第二个命令里的 $.name 是 JSONPath 语法$ 表示根节点.name 表示取根节点下的 name 字段。这比 XPath 简单但写法上也有不少讲究。比如想取 skills 数组的第一个元素可以用 $.skills[0]想判断字段是否存在可以用 JSON.TYPE user:1001 $.name。文档结构越复杂越能体现出它比整串读写的优势。我实际感受是会话信息、用户资料、配置快照这类“半结构化、经常局部修改”的场景从原版迁移到 RedisJSON 后并发更新问题基本消失代码里也不需要再做序列化反序列化那一套了。3.2 RediSearch缓存层顺手把全文检索也干了如果不了解 Redis Stack你大概率不会把“搜索引擎”和“缓存”放在一个进程里。但 RediSearch 恰恰做了这件事。它支持哈希和 JSON 两种数据结构建索引支持全文检索、数值范围过滤、排序、聚合、甚至向量相似度搜索。我最早用它是在一个商品服务里给商品名称和描述做站内搜索效果确实比让我自己遍历所有商品再内存筛选好太多。建索引的逻辑是先告诉它哪些前缀的 key 要进索引再告诉它哪些字段按什么类型处理。比如商品 key 都是以 product: 开头里面有 name 和 price那就这么建FT.CREATE idx:product ON JSON PREFIX 1 product: \ SCHEMA $.name AS name TEXT \ $.price AS price NUMERIC然后搜“机械键盘”并按照价格从低到高排序FT.SEARCH idx:product name:机械键盘 SORTBY price ASC LIMIT 0 10FT.SEARCH 返回的结果会把整条文档带回来省去你查完索引再回 Redis 取数据的第二步。这一点在业务代码里非常舒服。RediSearch 的聚合是另一个亮点比如你想统计每个品牌下面有多少商品、平均价格多少一条 FT.AGGREGATE 就能出结果不需要把几万条商品拉到应用层 reduce。不过别因为功能多就贪心建索引本身要占内存字段越多索引越大索引创建的瞬间还可能阻塞主线程后面性能部分我会展开讲。3.3 RedisTimeSeries时序数据入库前先压缩Time Series 模块解决的是监控指标、传感器数据这类不停追加时间戳数值的场景。如果直接往 Redis 里写几百万个字符串 key内存开销大查询也不方便。Time Series 模块提供专门的数据结构每条记录是“时间戳 值”底层按块存储还支持自动压缩和聚合规则。基本用法TS.CREATE metric:cpu_usage RETENTION 86400000 TS.ADD metric:cpu_usage 1718000000000 42.5 TS.RANGE metric:cpu_usage 1718000000000 1718003600000 AGGREGATION avg 60000第一条创建一条保留 24 小时的时序超时的数据自动清理不需要你再写定时任务扫 key。第三条是范围查询按每 60 秒一个桶做平均值聚合非常适合做监控图表的数据源。我最喜欢的是 TS.CREATERULE它能在写入的同时自动把原始数据聚合成更粗粒度的另一条时序比如把 1 秒粒度聚合成 1 分钟粒度这样查询 30 天趋势的时候不用对几百万个点做聚合计算。这对监控系统来说几乎是刚需。要注意的是时序数据的 key 数量一多Docker 跑着没设内存上限很容易把宿主机内存吃爆最好给每个时序设置合理的 RETENTION宁可后面查不到太久远的数据也别让它无限增长。3.4 RedisBloom极低内存挡住不存在的 keyBloom 模块跟前面几个不同它不存储原始数据只维护一个概率结构用来回答“某个 key 肯定不存在或可能存在”。最典型的场景是防缓存穿透很多恶意请求会拿一串根本不存在的 ID 来打你的缓存接口如果每个请求都穿透到数据库数据库分分钟被拖垮。用法非常简单BF.RESERVE bf:product 0.001 100000 BF.ADD bf:product 1001 BF.EXISTS bf:product 1001 BF.EXISTS bf:product 99999第一行的两个参数分别是期望误判率0.1%和预计要加入的元素数量10 万个。这两个参数会直接决定底层位数组的大小。有一个近似公式可以估算内存位数组长度约等于-n * ln(p) / (ln 2)^2n 是元素数量p 是误判率。按 10 万个元素、0.1% 误判率算大概不到 200KB非常省。如果只加不涨误判率又会慢慢升高所以调参要给自己留余量。另外 Bloom 模块里还有 Cuckoo Filter支持删除元素布隆过滤器本身不支持删除所以如果你有频繁删除的需求可以用 CF 系列命令。但大多数接口防穿透场景都是只增不减BF 就够了。4. 组合起来用一次商品详情缓存加搜索引擎加防穿透4.1 场景设定和需要解决的问题单个模块的用法看明白之后最有价值的其实是把它们组合起来。我拿一个典型的电商商品服务来举例这个服务要解决四个问题商品详情缓存、商品名称搜索、按价格筛选、以及防止不存在的商品 ID 打爆数据库。原版 Redis 的做法是详情用字符串缓存序列化后的商品 JSON搜索要么靠数据库 LIKE 要么靠外部搜索引擎防穿透要么用空值缓存要么自己维护一个布隆过滤器。每一样都能凑合用但凑起来很零散。用 Redis Stack一个进程全搞定而且都是原生命令级操作不需要额外中间件。4.2 用 JSON 模块做详情缓存与局部更新首先把商品详情存成 JSON 格式JSON.SET product:1001 $ {id:1001,name:机械键盘,brand:keychron,price:399,tags:[外设,无线]}然后用 JSON 命令做局部更新。比如用户下单后库存减一不需要整串更新只需JSON.NUMINCRBY product:1001 $.stock -1JSON.NUMINCRBY 是对数值类型字段做增减的原子操作比“读出来改后写回”安全得多。这个场景如果只用原版 Redis你多半会引入 Lua 脚本来保证原子性现在用 JSON 模块原生命令省了一层事。4.3 用 Search 模块做标题搜索与价格筛选商品数据在 JSON 里搜索模块可以直接对它建索引不需要另一份冗余结构。索引建好后即便后面新增的 product: 开头的 key也会自动进入索引前提是它在 PREFIX 1 product: 指定的前缀范围内。FT.CREATE idx:product ON JSON PREFIX 1 product: \ SCHEMA $.name AS name TEXT \ $.brand AS brand TAG \ $.price AS price NUMERIC \ $.tags[*] AS tags TAG这里有一个细节品牌用 TAG 类型而不是 TEXT因为品牌适合精确匹配和分类过滤不适合分词。TAG 类型查询要用大括号包起来比如FT.SEARCH idx:product brand:{keychron} price:[300 500] LIMIT 0 10这句话的意思是品牌是 keychron、价格在 300 到 500 之间的商品取前 10 条。TEXT 和 TAG 用错是新手最容易犯的错误搞错了搜出来的结果要么是 0要么把不该分词的词拆碎了。记住一个判断口诀需要分词模糊搜用 TEXT需要精确分类过滤用 TAG。4.4 用 Bloom 模块挡掉恶意扫描商品 ID 通常是自增数字恶意请求很容易连续遍历不存在的 ID。做法是在查询流程前面加一道布隆过滤器请求进来先 BF.EXISTS bf:product {id}如果返回 0说明这个 ID 大概率不存在直接返回空不打数据库如果返回 1说明可能存在继续查缓存或数据库数据库中查到后把真实存在的 ID 加到布隆过滤器里这里要注意布隆过滤器是存在判断不是缓存所以不会因为 TTL 过期导致数据丢失。初始化参数方面我建议按业务三年内的商品总量再乘 2 来设置容量因为加元素不加容量会让误判率上升。误判率我一般设 0.001也就是千分之一足够挡住绝大多数穿透请求。4.5 补上 TTL、命名与数据一致性方案组合方案里最容易被忽略的是命名规范和失效策略。我建议所有 key 统一用业务前缀加冒号分层比如 product:1001、idx:product、bf:product这样后续用 SCAN 做统计也好分类。再一个就是 TTL。布隆过滤器不能设置 TTL因为删除 key 相当于重建会把所有已存在的 ID 判定消失。但商品详情 JSON 可以给一个短 TTL比如 30 分钟缓存自动过期后再从数据库加载。这里就有一个一致性问题如果数据库里的商品改了缓存 TTL 没到怎么办比较粗暴也实用的做法是双写修改数据库成功后顺便调 JSON.SET 覆盖缓存如果事务失败就 DEL product:1001 让缓存失效。加上 TTL 兜底基本能接受。整个组合方案跑下来的感觉是架构上少了一堆外部依赖运维上只需要盯一个 Redis 实例业务代码也不用维护两套不同中间件的客户端。对于中小型服务这种“一个进程解决缓存、搜索、防穿透”的设计性价比确实很高。5. 那些看不见的内存和协议门槛踩过才懂5.1 RESP2 和 RESP3 的客户端兼容问题Redis 从 6.0 开始支持 RESP3 协议Redis Stack 的模块大量依赖响应类型更丰富的 RESP3。RESP2 时代返回的很多是字符串数组RESP3 能返回 Map、Double 等结构化类型。问题是如果你的客户端库太老默认协商的是 RESP2会发现部分模块命令返回的数据格式诡异。我遇到过的情况是用某个老版本客户端去执行 FT.AGGREGATE结果解析出来的结果全是字符串拼接得不到结构化字段。排查了半天最后发现是客户端桶不支持 RESP3。解决办法很直接升级客户端库到支持 RESP3 的版本比如较新的 redis-py、Jedis、node-redis。如果你的客户端在连接参数里能设置 protocol3手动声明。实在不想升级就还在 RESP2 模式下跑但最好别把聚合这种复杂响应类型的命令用在生产代码里。这个问题网上资料少也不容易想到但我身边的同事真踩过。所以装完 Stack先查一查你用的客户端库版本和协议支持情况能省下后面很多排查时间。5.2 索引内存比数据本身还大怎么预估RediSearch 建索引的时候索引结构会单独占用内存。字段越多的类型索引越大特别是 TEXT 类型要分词分词后每个词都要建倒排表内存开销很可观。可能你整个商品 JSON 原始数据只有 100MB但索引内存反而到了 300MB。这个现象在 INFO memory 里能看出来used_memory 会比你预想高不少。要精确区分数据内存和索引内存可以用 MODULE 的命令或者查看内存分析工具。但更务实的做法是在设计阶段就控制只给需要搜索的字段建索引别把什么备注、日志字段统统塞进 SCHEMA。TEXT 字段能不建全文就不要建没搜索需求的字段用 TAG 或者直接不索引。考虑给索引设置上限比如 FT.CONFIG 调整内存限制超过阈值索引不再写入避免整个 Redis OOM。我在测试环境碰到过一次商品详情就几千条建了 6 个字段的索引其中两个大字段用了 TEXT结果内存直接比无索引时大了 4 倍。后来把那两个字段改成 TAG或者去掉索引内存立刻降下来。所以索引不是“建了就完事”它是要用内存换查询速度的你得知道这笔账怎么算。5.3 阻塞与持久化的取舍大对象操作要谨慎Redis 单线程执行命令Redis Stack 的模块命令也不例外。这就意味着一条很大的 JSON 写入、一次很大的 FT.CREATE、一次复杂的聚合查询都会阻塞其他命令的执行导致整个实例的延迟抖动。我实测过往 RedisJSON 里写入一个几 MB 的 JSON 文档解析和构建内部结构花了几十毫秒这几十毫秒内其他读写命令全部排队。所以对于大 JSON 写入要么在业务低峰期做要么拆分成小块写入。Search 模块建索引也是一样第一次 FT.CREATE 如果覆盖几百万个 key最好是凌晨跑或者分批用 PREFIX 范围控制。持久化方面还有一个容易忽略的点模块产生的数据结构和索引在 RDB 持久化和 AOF 重写时都会被序列化。不同模块有自己的序列化格式所以 Redis Stack 的 RDB 文件只能由同样模块版本兼容的实例加载。升级的时候如果只升级 Redis 版本而模块版本不匹配可能直接加载失败。我的建议是升级前先备份最好先在一个临时实例上恢复一下 RDB 验证能不能起来再滚到生产。6. 什么时候该选 Stack什么时候继续用原版6.1 适合接入的三种典型架构不是所有场景都该用 Redis Stack过早把模块全启用了反而多占内存。我梳理下来它特别适合这三类架构第一类是“缓存加搜索一体化”的业务。比如商品、文章、用户列表这类既要缓存又要检索的场景Stack 把缓存和搜索放一起省掉一个 Elasticsearch 或 Solr 的重型依赖。第二类是“高并发防穿透加”的接口层。电商、内容站、账务系统总会遇到扫 ID 的恶意流量Bloom 过滤器加缓存是一套标准方案Stack 内置之后不需要再单独引入其他服务。第三类是“监控和缓存共存”的运维场景。应用服务本身用 Redis 做缓存同时又要采集一些业务指标比如接口调用量、耗时分布Time Series 模块可以直接塞到同一个实例里不一定非要再搭一套时序数据库。6.2 集群模式和模块的兼容性现实要提醒的是Redis Stack 在单机、主从、哨兵模式下都比较好使但在 Redis Cluster 模式下有些模块的命令支持是受限的。搜索模块在集群环境下可以做分布式搜索但需要特殊的部署方式和配置JSON 模块在集群模式下的跨 slot 操作也会受限。这些坑文档里都有说明但很多人没仔细看导致搭好了集群才发现某个命令报错。我自己的体会是如果业务量还没到必须上集群的地步优先用单机配持久化省心得多如果真到了集群规模先把模块命令的集群兼容性表拉出来一个一个对照业务场景别等上线了再试错。对于新项目还有一个“反向选择”的思路先用原版 Redis 把基本缓存跑通确实遇到模块需求再迁移到 Stack迁移成本其实很低因为底层数据格式兼容。不用一开始就把所有模块都用上。6.3 我现在的选型心法和上手建议整理一下我的选型心法内存预算够、想省架构组件、团队愿意接受新命令Redis Stack 值得用反之如果只有几百 MB 内存、业务纯粹是 KV 缓存老老实实跑原版 Redis别为了“新功能”而扩容。如果你决定上手建议按这个顺序学先把 JSON 模块用熟因为它带来的收益最直观、风险最小接着玩 Search从最简单的 TAG 过滤开始再碰 TEXT 全文索引然后加 Bloom 防穿透最后在需要监控指标时再碰 Time Series。不要一上来四个模块一起上出了问题你都分不清是哪个模块引起的。最后分享一个小习惯我会在每次升级 Redis Stack 版本前跑一遍自己整理的“模块冒烟脚本”集中执行 JSON 写入、索引创建、时序写入、布隆判断这几类命令确认返回结果符合预期再动生产。版本升级这种事官方文档写得再清楚也顶不上自己亲手验证一遍来得踏实。
