方案介绍

数据选型

首先声明：以下我要介绍的这套缓存方案，它的缓存数据是基于 RedisJSON 实现的。之所以选择 RedisJSON 而非传统的 String (Plain KV)，本质上是从把 Redis 当成一个简单的缓存盒子进化到了 把 Redis 当成一个可索引的文档数据库。这使得它具备如下的核心优势：

环境和背景说明

依赖环境

Java Version：17

Spring Boot Version：3.5.9

Redis Server with RedisJSON and RediSearch：8.2.0

简单说明

为什么需要 RedisJSON？

在没有 RedisJSON 之前，我们要存储一个 User 对象，通常有两种苦逼做法：

• 方案 A（String 序列化）：把整个对象转成 JSON 字符串存入。痛点是如果你只想修改一个字段，你必须本地处理和网络传输整个字符串。在高并发下，这极其浪费带宽且存在并发覆盖风险。
• 方案 B（Hash 散列）：用 Redis Hash 存。痛点是无法处理嵌套结构。如果用户的address是个复杂的嵌套对象，Hash就没辙了。

RedisJSON 的出现： 让你能像操作 MongoDB 一样，直接在 Redis 内部解析、查询和部分修改 JSON 文档。并且 JSON.SET (NX/XX) 更新某个字段是原子的，这完美解决了 “读取-修改-写回” 产生的并发冲突。

RediSearch 概述

打个形象的比喻，如果将 RedisJSON 比作一个存储复杂结构的“抽屉”，那么 RediSearch 就是给所有抽屉装上“实时雷达” 的高性能搜索引擎。在 Redis 8.2+ 的语境下，RediSearch 不再仅仅是一个简单的关键词匹配工具，它已经演变成一个多模态搜索与索引引擎。关于在 RediSearch 和 ElasticSearch 技术选型的问题，在《RediSearch 和 RedisJSON 的编译安装》中我们已经有所介绍，不再赘述。

现象描述

在 redis 单机搭建和集群搭建测试的过程中，我发现一个非常诡异的问题，那就是相同的测试数据，单机和集群对 RedisJSON JSON.MGET 这条指令的执行结果不一致。准确的说是：