Redis实现分页与多条件模糊查询的组合方案

  在常规业务中，分页与模糊查询十分普遍，通过数据库一条SQL即可轻松完成，但数据一旦落到Redis缓存层，由于缺乏类似SQL的查询语义，直接实现变得困难，需要探索替代方案。

  Redis是一种key-value内存数据库，提供GET/SET、List、Set、Hash、ZSet等指令，但不支持类似WHERE name LIKE '阿%' AND gender = '女' ORDER BY created_at DESC LIMIT 40, 20的复杂查询。要在Redis中同时实现分页与多条件模糊匹配，必须通过数据结构自行组合。

  通常会踩到这件事的业务场景有几类:

1. 评论、动态、消息流这类时间线数据，热点都在缓存里
2. 高并发写入的中间结果，先在Redis缓冲、稍后再持久化到数据库
3. 实时统计类的看板，MySQL扛不住的查询被前移到缓存
4. 某些数据本身就不落库，例如临时排行榜、活动期间的会话数据

  这些场景的共同特征是数据要么暂时不在数据库里，要么放在数据库里也来不及查。下面要解决的，就是在这种约束下，怎么把分页和多条件模糊查询拼起来。

二、分页:为什么首选 ZSet

  Redis里能支撑"取第几页、每页几条"的结构有两个:List和ZSet。看似都能做，但ZSet几乎在所有场景都更合适。

2.1 ZSet 的核心指令

  ZSet全称Sorted Set，即有序集合，每个元素同时绑定一个score，集合按score自动排序。和分页相关的指令主要有这几个:

  业务里常见的做法是把时间戳作为score，于是"最新发布"自然就是ZREVRANGE key 0 -1，分页就是ZREVRANGE key (page-1)*size page*size-1。这套语义和SQL里的ORDER BY created_at DESC LIMIT ?, ?几乎一一对应。

2.2 分页代码示例

  用Spring Data Redis的RedisTemplate实现一个朴素分页接口:

public List pageComments(String bizId, int page, int size) {    String key = "comments:" + bizId;    long start = (long) (page - 1) * size;    long end = start + size - 1;    Set jsonSet = redisTemplate.opsForZSet()            .reverseRange(key, start, end);    if (jsonSet == null || jsonSet.isEmpty()) {        return Collections.emptyList();    }    return jsonSet.stream()            .map(json -> JSON.parseObject(json, Comment.class))            .collect(Collectors.toList());}public void addComment(String bizId, Comment c) {    String key = "comments:" + bizId;    redisTemplate.opsForZSet()            .add(key, JSON.toJSONString(c), c.getCreateTime().getTime());}

2.3 ZSet 相比 List 的优势

  很多人会说"用List也能分页"，做的方式无非是LPUSH + LRANGE。但在生产环境里，List一旦遇到下面任何一项，就开始难受:

1. 乱序写入:List只能按写入顺序排，业务里却经常出现"补录"、"修正时间戳"等需要重排序的情况
2. 范围筛选:想"取过去24小时内的评论"，List拿不到这个能力，ZSet一个ZRANGEBYSCORE就够
3. 去重:ZSet的member是唯一的，配合业务主键能避免重复插入;List不去重，需要业务自己保证

  唯一一种List更合适的场景是:允许重复member、且不需要任何排序变更，比如纯粹的日志缓冲。除此之外，ZSet几乎都是更好的选择。

2.4 深翻页的隐藏代价

  ZSet的ZREVRANGE表面上是O(log N + M)，但在N上千万、page翻到几千页时，依然会拖慢响应。生产里通常会做两件事:

1. 限制最大可翻页深度，比如最多100页，剩下的引导用户用筛选条件而不是无脑翻页
2. 改成游标式分页:把"上一页最后一条的score"传回客户端，下一次直接ZREVRANGEBYSCORE key (lastScore -inf LIMIT 0 size，避免offset越深越慢

  游标分页的代码示例:

public List pageByCursor(String bizId, Long lastScore, int size) {    String key = "comments:" + bizId;    double max = (lastScore == null) ? Double.POSITIVE_INFINITY : lastScore - 1;    Set set = redisTemplate.opsForZSet()            .reverseRangeByScore(key, Double.NEGATIVE_INFINITY, max, 0, size);    // ...}

三、多条件模糊查询:基于 Hash 与 HSCAN

  ZSet解决了分页，但解决不了"按条件筛选"。要在Redis内部完成模糊匹配，目前业界最常见的做法是借助Hash + HSCAN。

3.1 思路:把条件字段编码进 field

  核心点是设计Hash的field命名规则，把所有可能参与模糊匹配的字段拼进去。例如用户数据，约定field形如:

:<姓名>:<性别>

  写入示例:

HSET user_index "1001:阿强:男" "{...用户详情JSON...}"HSET user_index "1002:阿琳:女" "{...用户详情JSON...}"HSET user_index "1003:张伟:男" "{...用户详情JSON...}"

  查询时利用HSCAN的MATCH模式:

# 所有女性HSCAN user_index 0 MATCH *:*:女 COUNT 1000# 姓阿的全部HSCAN user_index 0 MATCH *:阿*:* COUNT 1000# id 前缀 100 的男性HSCAN user_index 0 MATCH 100*:*:男 COUNT 1000

  HSCAN是渐进式扫描，单次只返回一小部分，配合返回的cursor反复调用，直到cursor归零代表遍历结束。它比KEYS安全得多——不会阻塞Redis主线程。

3.2 为什么坚决不用KEYS

  新人很容易写出KEYS *:阿*:*这种代码。KEYS是阻塞式的，会扫描全库，在生产环境上百万key的实例里，一次调用足以让整个Redis服务卡顿数秒，后果是所有读写请求一起阻塞，雪崩级的故障。所有线上代码都应当用SCAN系列指令(SCAN、HSCAN、SSCAN、ZSCAN)替代KEYS与HGETALL式全量遍历。

3.3 模式匹配的局限

  HSCAN MATCH用的是glob风格通配符:*、?、[]。这意味着:

1. 它能做前缀/后缀/包含匹配
2. 它做不了真正的全文检索(分词、相关性排序、拼写纠错)
3. 它做不了多字段交集，只能在field名里把字段拼起来用通配符近似实现

  如果业务方真正需要的是"在十万条描述里找语义相近的文本"，那就别在原生Redis里硬刚，直接上RediSearch、Elasticsearch或者向量数据库。本文要谈的方案，针对的是中等规模(几万到几百万key)、字段维度可枚举的过滤性查询。

3.4 渐进式扫描的代码模板

public List scanByPattern(String hashKey, String pattern) {    List matched = new ArrayList<>();    ScanOptions options = ScanOptions.scanOptions()            .match(pattern)            .count(1000)            .build();    try (Cursor> cursor =                 redisTemplate.opsForHash().scan(hashKey, options)) {        while (cursor.hasNext()) {            Map.Entry entry = cursor.next();            matched.add(entry.getKey().toString());        }    }    return matched;}

  要注意COUNT只是提示，不是返回上限。Redis可能返回多于或少于这个值的元素，业务侧要做好"边扫边过滤"的心理预期。同时，扫描期间Hash内容可能发生变化，HSCAN提供的是"弱一致"语义——不会漏掉一直存在的field，但中途新增/删除的field可能返回也可能不返回，这点和MySQL的快照读完全不是一回事。

四、组合方案:把分页和模糊查询拼在一起

  单独看，ZSet解决分页、Hash + HSCAN解决条件过滤。问题来了——HSCAN的结果是无序的，单次也只是部分结果，直接拿它做"取第3页20条"完全行不通。怎么办?

4.1 总体思路

  业内比较成熟的做法可以归纳为四步:

1. 数据写入:所有原始数据按"条件编码field"写到一张大Hash里
2. 条件转匹配串:把用户传入的多条件请求，转成一个统一格式的匹配串，例如*:阿*:女
3. 结果集索引:以匹配串本身作为ZSet的key，第一次查询时用HSCAN把所有命中field写进这个ZSet，并给ZSet设过期
4. 分页读取:后续相同条件的请求直接走ZSet分页，不再扫描Hash

  整体流程画出来就是这样:

4.2 数据结构设计

  以一个用户检索场景为例:

# 原始数据,HASH 类型KEY    user_indexFIELD  :<姓名>:<性别>:<城市>VALUE  {"id":1001,"name":"阿强","gender":"男","city":"上海", ...}# 结果集索引,ZSET 类型KEY    user_index:query:*:阿*:*:上海MEMBER :<姓名>:<性别>:<城市>SCORE  排序字段(注册时间、id 等)

  ZSet的key由业务前缀+匹配串拼成，方便统一管理;member直接复用Hash的field，回查时HGET user_index 即可。

4.3 关键代码

public PageResult queryUsers(UserQuery q, int page, int size) {    String pattern = buildPattern(q);                  // 例如 "*:阿*:*:上海"    String zsetKey = "user_index:query:" + pattern;    Boolean exists = redisTemplate.hasKey(zsetKey);    if (Boolean.FALSE.equals(exists)) {        rebuildIndex(zsetKey, pattern);                // 第一次查询,构建索引    } else {        redisTemplate.expire(zsetKey, Duration.ofMinutes(10));   // 命中则续期    }    long start = (long) (page - 1) * size;    long end = start + size - 1;    Set fields = redisTemplate.opsForZSet()            .reverseRange(zsetKey, start, end);    if (fields == null || fields.isEmpty()) {        return PageResult.empty();    }    List