生产环境下Redis按KEY模式批量查询的最优方案咨询

1. 调优SCAN参数+分批次低峰执行 #

这是当前场景下最省心的平衡方案：

• 不用改现有存储结构，把SCAN的COUNT值调到1000-2000区间——既不会像默认值10那样遍历过慢，也不会因10000的高值给CPU带来突发压力。
• 执行时拆分SCAN循环，每次迭代后休眠10-50ms，把CPU负载分散开，避免Redis单线程被长时间占用。
• 选择业务低峰期执行查询，进一步降低对生产的影响。
• 示例命令流程：

  # 初始游标0，匹配目标前缀，COUNT设为1500
  SCAN 0 MATCH server.overview.map:* COUNT 1500
  # 用返回的游标继续迭代，直到游标回到0完成遍历
  SCAN <返回的游标> MATCH server.overview.map:* COUNT 1500
  

2. 用Hash结构归类存储同前缀键 #

如果这类前缀查询是高频需求，重构存储结构是一劳永逸的办法：

• 把所有server.overview.map:前缀的键，存入名为server.overview.map的Hash结构中——原键的后缀作为Hash的field，原键对应的值作为Hash的value。
• 查询时直接用HGETALL server.overview.map或者HKEYS server.overview.map就能一次性获取所有目标条目，彻底避免遍历全量键空间。
• 就算某个前缀的条目超1M，Hash的存储开销也远小于单独存1M个字符串键（Redis单个键的元数据开销不小），反而能节省内存。

3. 键空间通知+实时维护集合 #

如果需要实时获取这类前缀的键，可以尝试这个方案：

• 开启Redis的键空间通知，监听__keyspace@0__:server.overview.map:*类型的事件，当有符合前缀的键创建或删除时，让客户端实时维护一个Set集合。
• 查询时直接读取这个Set即可，代价是需要额外的客户端监听逻辑，以及集合的内存开销——但180条的场景内存可忽略，就算超1M条，开销也比存1M个单独键小。

为啥不选其他方案？ #

• KEYS命令：会遍历全部12M条键，直接导致Redis阻塞，生产环境绝对禁用。
• 直接设COUNT=10000：单次迭代处理大量键，短时间内CPU占用飙升，会拖慢其他业务请求的响应速度。

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