1. Redis模糊查询的核心场景与价值在真实业务场景中我们经常需要处理这样的需求根据不完整的关键词查找匹配的数据记录。比如用户只记得订单号的前几位、商品名称包含某个字词、或者需要批量操作符合特定模式的所有缓存键。这种部分匹配的查询需求正是Redis模糊查询大显身手的地方。Redis作为高性能的键值数据库提供了多种原生的模糊查询机制。与关系型数据库的LIKE操作不同Redis的模糊查询在设计上有几个显著特点基于键名模式匹配而非值内容使用通配符语法而非正则表达式执行过程完全在内存中完成单线程模型保证原子性操作重要提示生产环境中直接使用KEYS命令可能导致性能问题实际开发中更推荐SCAN命令配合模式匹配。2. Redis支持的三种通配符详解2.1 星号(*)通配符任意长度匹配星号是Redis模糊查询中最常用的通配符它可以匹配零个或多个任意字符。比如# 查找所有以user:开头的键 KEYS user:* # 查找所有包含session的键 KEYS *session* # 查找所有以.jpg结尾的键 KEYS *.jpg我在实际项目中发现星号通配符特别适合以下场景批量清理特定前缀的缓存如活动结束后清理所有campaign:*键统计某一类键的数量如统计所有product:*键跨服务数据隔离不同服务使用不同前缀2.2 问号(?)通配符单字符精确匹配问号通配符用于精确匹配单个字符的位置。这在需要固定长度键名时特别有用# 匹配第三个字符是b的5字符键名 KEYS ??b?? # 匹配形如user-1-profile的键 KEYS user-?-profile一个实际案例我们曾用这种模式匹配临时生成的验证码键如sms:138****1234其中手机号中间四位被隐藏正好可以用?替代。2.3 方括号([])通配符字符集匹配方括号提供更精细的字符级控制可以指定一个字符的可选范围# 匹配以a或b开头的键 KEYS [ab]* # 匹配第二个字符是数字的键 KEYS ?[0-9]* # 排除特定字符匹配不以数字结尾的键 KEYS *[^0-9]在日志处理系统中我们曾用[0-9]模式匹配按小时分割的日志键如log:2023-08-[01-24]实现按时间范围批量操作。3. 生产环境最佳实践与性能优化3.1 KEYS命令的潜在风险虽然KEYS命令简单直观但在生产环境直接使用可能导致严重问题阻塞式执行KEYS会遍历整个键空间在大型Redis实例上可能耗时数秒单线程阻塞执行期间其他命令无法处理导致服务不可用内存消耗返回大量键名时可能消耗大量内存去年我们一个线上事故就是因为在高峰期执行了KEYS *查询导致核心业务接口超时。事后我们制定了严格的Redis操作规范。3.2 SCAN命令的安全替代方案Redis 2.8引入的SCAN命令是更好的选择它具有以下优势非阻塞迭代分批返回结果不阻塞主线程可中断执行每次调用只返回部分结果游标管理支持断点续查典型使用模式# 第一次扫描 SCAN 0 MATCH user:* COUNT 100 # 后续扫描使用返回的新游标 SCAN 176 MATCH user:* COUNT 100实测对比100万键的Redis实例操作方式执行时间内存峰值对其他请求影响KEYS *2.3s120MB完全阻塞SCAN多次调用共1.8s10MB几乎无感知3.3 高级模式匹配技巧结合多个通配符可以实现更复杂的匹配逻辑# 匹配以order_开头第7位是1-5的数字长度8位的键 SCAN 0 MATCH order_[1-5]??? COUNT 100 # 匹配包含temp且不以数字结尾的键 SCAN 0 MATCH *temp*[^0-9] COUNT 100在电商系统中我们使用这种组合模式清理过期的临时购物车数据cart:temp:[0-9][0-9][0-9][0-9]-*4. 实战案例用户会话管理系统4.1 系统架构设计假设我们需要管理用户会话数据键的格式为session:{userId}:{deviceType}其中userId8位数字deviceTypeweb/mobile/tablet4.2 关键操作实现批量查询移动端会话SCAN 0 MATCH session:*:mobile COUNT 500统计各类设备会话数# 使用管道提高效率 echo -e SCAN 0 MATCH \session:*:web\ COUNT 1000\nSCAN 0 MATCH \session:*:mobile\ COUNT 1000 | redis-cli --pipe清理过期会话结合Lua脚本保证原子性local keys redis.call(SCAN, 0, MATCH, session:*, COUNT, 500) for i,key in ipairs(keys[2]) do if redis.call(TTL, key) 0 then redis.call(DEL, key) end end return keys[1] -- 返回新游标4.3 性能优化记录我们记录了不同查询方式的性能对比单位ms数据量KEYS直接查询SCAN(COUNT100)SCAN(COUNT500)Lua脚本批量处理1万4558322810万420205180150100万内存溢出920850780从数据可以看出对于大数据集SCAN比KEYS更稳定可靠适当增大COUNT值能提升效率但单次内存消耗会增加Lua脚本批量处理是最优方案5. 常见问题排查与解决方案5.1 模式匹配失效问题现象通配符查询返回空结果但键确实存在排查步骤确认键名中的特殊字符是否被转义检查是否有不可见字符如空格、制表符使用redis-cli --raw选项查看原始键名尝试简化模式逐步测试案例我们曾遇到user:123*无法匹配user:12345的情况最终发现键名实际包含尾随空格。5.2 内存消耗过高问题现象执行模糊查询后Redis内存激增解决方案对于SCAN命令降低COUNT参数值建议从100开始调优使用管道技术分批处理结果考虑在从库执行查询操作对结果集进行流式处理避免全量存储在内存5.3 集群环境特殊考量在Redis Cluster中需要注意SCAN命令只在当前节点执行需要遍历所有主节点并合并结果跨槽位的键无法通过单个模式匹配我们开发的集群版扫描脚本示例#!/bin/bash for port in {7000..7005}; do echo Scanning node at port $port redis-cli -c -p $port SCAN 0 MATCH $1 COUNT 100 done6. 扩展应用与进阶技巧6.1 结合Redis模块实现增强查询对于更复杂的查询需求可以考虑RediSearch全文搜索功能RedisJSONJSON文档查询RedisGraph图关系查询比如使用RediSearch实现模糊搜索FT.CREATE idx ON HASH PREFIX 1 product: SCHEMA name TEXT FT.SEARCH idx %手机% LIMIT 0 106.2 客户端实现模式各语言客户端通常提供更友好的模糊查询封装Python示例def scan_keys(pattern, batch_size100): cursor 0 while cursor ! 0: cursor, keys r.scan(cursorcursor, matchpattern, countbatch_size) yield from keysJava示例public ListString scanKeys(Jedis jedis, String pattern) { ListString keys new ArrayList(); String cursor ScanParams.SCAN_POINTER_START; ScanParams params new ScanParams().match(pattern).count(100); do { ScanResultString result jedis.scan(cursor, params); keys.addAll(result.getResult()); cursor result.getCursor(); } while (!cursor.equals(ScanParams.SCAN_POINTER_START)); return keys; }6.3 监控与性能分析建议对模糊查询操作进行监控使用SLOWLOG获取慢查询监控内存变化趋势记录SCAN迭代次数我们采用的Prometheus监控指标示例redis_scan_operations_total{patternuser:*} redis_scan_duration_seconds{patternuser:*} redis_scan_keys_returned{patternuser:*}在键名设计阶段就考虑未来的查询需求比如将可查询字段放在固定位置使用分隔符划分字段边界避免使用特殊字符作为键名组成部分比如user:{region}:{id}:profile这种结构可以轻松实现按地区查询user:cn:*
