RedisJSON是Redis官方推出的扩展模块，它在Redis内部实现了标准的JSON数据结构，使得用户可以直接以文档形式存储、查询和修改数据，而不必把JSON序列化成字符串再整体读写。传统做法下，哪怕只改一个嵌套字段也要先取全量、改完再写回，高并发时极易形成瓶颈。RedisJSON通过一套路径语法和专用命令，让文档型数据的操作变得精准且轻量。
模块启用与文档写入
在使用RedisJSON之前，必须确保Redis服务器加载了ReJSON模块。常见方式是在启动配置里加入loadmodule指令指向重新编译好的模块文件，或者使用支持模块的Redis发行版如Redis Stack。启动后可以通过命令JSON.SET把一段JSON文档关联到某个key上，例如把用户基础信息写成嵌套对象，而不用关心应用层用什么语言序列化。
写入时路径参数通常用根符号$或.来表示整文档替换，也可以指定具体路径只设置某一子树。RedisJSON会校验JSON语法合法性，非法结构会直接报错，这比单纯存字符串更早发现数据问题。对于已经存在的key，JSON.SET默认覆盖对应路径，因此批量初始化缓存或会话数据时非常直观，也方便后续局部修正。
路径查询与局部更新
查询是RedisJSON的强项。JSON.GET支持传入多个路径，只返回关心的字段，比如取出订单文档里的状态和金额，避免传输整个大文档。路径语法类似JSONPath，可以用点号进入对象、用中括号加索引进数组，也能使用过滤表达式筛选数组元素，这让服务端就能完成很多原本要在应用里写的逻辑。
局部更新命令如JSON.SET针对子路径、JSON.DEL删除字段、JSON.NUMINCRBY对数字做原子自增，都只锁定相关部分。假设一个文章统计文档包含阅读数和点赞数，高并发下用JSON.NUMINCRBY自增阅读量，不会干扰点赞字段，也不需要应用先读后写。这种细粒度操作显著降低了网络往返和序列化开销。
数组与复杂结构处理
文档型数据常包含数组，RedisJSON提供JSON.ARRAPPEND、JSON.ARRPOP等命令操作数组首尾或指定位置。例如把用户行为流水以数组形式追加到固定key，既能保留顺序又不必重写整个列表。对于嵌套较深的配置树，也可以用路径直达某层参数，实现配置热更新而不断开业务读写。
需要注意数组无限增长会带来内存压力，可结合JSON.ARPTRIM限制长度，只保留最近若干条。和哈希、列表等原生结构相比，RedisJSON在表达层级关系上更自然，但内存占用稍高，因此在日志型、画像型等读多写少且结构变动少的场景里收益最大。
性能与使用注意
虽然RedisJSON提升了操作便利性，但路径解析本身有成本。非常频繁且极简的计数场景，仍可用原生字符串或哈希；而当文档结构复杂、字段更新分散时，它的优势才明显。建议把大文档按业务拆成多个key，避免单key过大导致命令执行时间变长。
另外，集群模式下要确保相关文档key路由到同一槽位以便后续扩展事务或跨key脚本。备份方面，RDB和AOF都能正常持久化JSON类型，运维习惯无需大改。总体来看，把RedisJSON当作“内存里的文档数据库”来用，能大幅简化应用代码，同时维持Redis原有的低延迟特性。
| 操作类型 | 常用命令 | 适用场景 |
|---|---|---|
| 写入文档 | JSON.SET | 初始化用户画像、配置缓存 |
| 读取字段 | JSON.GET | 按需获取部分属性减少传输 |
| 数值修改 | JSON.NUMINCRBY | 计数器、统计指标原子更新 |
| 数组操作 | JSON.ARRAPPEND | 行为流水、消息列表追加 |
小结
RedisJSON把文档型数据的处理能力带进了Redis，让开发不必在“整体字符串”和“多key拆解”之间纠结。理解路径语法、熟悉局部更新命令，再根据业务特点合理拆分文档，就能用更少的代码支撑更灵活的数据结构。对于已经依赖Redis做缓存或会话存储的系统，引入该模块通常只需少量改造即可见效。