GemFire与Redis对比：Redis替代GemFire OQL的代码改造及存储咨询

我之前也遇到过类似的迁移需求，从GemFire转到Redis，最大的痛点就是GemFire的OQL对嵌套对象的查询太省心了，而Redis确实需要提前规划数据结构。下面分享一些我实际落地的思路：

核心差异梳理 #

GemFire：可以直接存储完整的父对象，OQL支持直接遍历深度嵌套的集合/对象属性，存储时无需额外设计，查询时写类似SQL的语句就能搞定。
Redis：本质是键值存储，默认不支持直接查询嵌套结构，必须根据查询需求提前拆分存储结构，或者借助扩展功能实现。

Spring/Spring Boot下的具体实现方案 #

1. 传统Redis结构拆分（无扩展依赖） #

如果只用标准Redis（不引入Redis Stack之类的扩展），就得手动拆分数据结构来适配查询需求：

• 对于包含嵌套集合的父对象，比如User里有List<Order>：
  • 用Hash存储User的基础属性：user:{userId} -> {name: "xxx", age: 30...}
  • 单独用Set或List存储该用户的订单ID集合：user:orders:{userId} -> [order1, order2...]
  • 如果需要查询“所有包含特定订单的用户”，还要反向维护一个索引order:users:{orderId} -> [userId1, userId2...]
• 在Spring里可以用RedisTemplate或者StringRedisTemplate来封装这些操作，也可以自定义RedisRepository的实现类来封装复杂查询逻辑，比如封装一个方法findUsersByOrderId(String orderId)，内部先查反向索引的Set，再批量查用户Hash。

2. 借助RedisJSON扩展（接近GemFire体验） #

如果可以引入Redis Stack（包含RedisJSON模块），就能直接存储JSON格式的完整对象，然后用JSONPath语法查询嵌套结构，这就和GemFire的OQL非常接近了：

• 存储时直接把完整的父对象序列化为JSON存入Redis：

  redisTemplate.opsForValue().set("user:" + userId, objectMapper.writeValueAsString(user));
  

• 查询时用RedisJSON的JSON.GET命令结合JSONPath，比如要找User的orders列表中包含orderId=123的用户，就可以用类似的命令：

  String jsonPath = "$[?(@.orders[*].id == '123')]";
  String result = redisTemplate.execute((RedisCallback<String>) connection -> {
      return new String(connection.execute("JSON.GET", "user:*", jsonPath));
  });
  

• Spring Boot里可以通过引入spring-boot-starter-data-redis配合支持RedisJSON的客户端（比如jedis或lettuce-core），或者用第三方封装的starter来简化操作。

3. Spring Data Redis的进阶封装 #

如果不想直接写Redis命令，可以利用Spring Data Redis的@Query注解（针对Redis Repository）来定义查询，比如结合RedisJSON的语法：

@Repository
public interface UserRepository extends RedisRepository<User, String> {
    @Query("JSON.GET user:* $[?(@.orders[*].id == ?0)]")
    List<User> findUsersByOrderId(String orderId);
}

不过这里需要注意，Redis Repository对RedisJSON的支持需要版本兼容，建议用较新的Spring Data Redis版本。

改造量的优化建议 #

• 优先评估是否可以引入Redis Stack，这能大幅减少数据结构拆分的工作量，代码改造主要集中在序列化/反序列化和查询语句的替换上，从GemFire的OQL转到JSONPath学习成本也不高。
• 如果不能引入扩展，建议封装统一的操作工具类，把数据拆分、索引维护的逻辑封装起来，上层业务代码尽量和操作Redis的细节解耦，这样后续维护成本更低。
• 对于复杂的嵌套查询，可以考虑把常用的查询结果做缓存，比如提前计算并存储“包含特定订单的用户ID集合”，避免每次查询都做全量扫描。

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