假如Redis里面有1亿个key,其中有10w个key是以某个固定的已知的
mhr18 2025-03-24 18:17 20 浏览 0 评论
在 Redis 中查找以特定前缀开头的所有 key,在拥有 1 亿个 key 的情况下,需要非常小心,避免使用会阻塞 Redis 服务器的命令。 直接使用 KEYS prefix* 命令是 绝对不推荐 的,因为它会遍历整个 key 空间,在生产环境中会导致 Redis 性能急剧下降甚至崩溃。
以下是几种查找以特定前缀开头的 key 的方法,以及它们的优缺点和适用场景:
1. 使用 SCAN 命令 (推荐)
SCAN 命令是 Redis 官方推荐的迭代 key 空间的方式,它不会阻塞服务器,而是使用游标 (cursor) 分批次地返回 key。
- 优点:非阻塞: 不会阻塞 Redis 服务器,对性能影响较小。可控: 可以通过 COUNT 参数控制每次迭代返回的 key 的数量,平衡性能和效率。
- 缺点:非原子性: 在 SCAN 迭代过程中,key 可能会被修改或删除,因此返回的结果可能不是完全一致的快照。需要客户端处理: 需要在客户端代码中循环调用 SCAN 并处理游标,直到游标返回 0。
- 适用场景: 大多数情况下,特别是生产环境,这是最安全和推荐的方法。
示例 (Python redis-py):
python复制代码import redis
r = redis.Redis(host='localhost', port=6379, db=0)
prefix = "your_prefix:" # 替换为你的前缀
keys_with_prefix = []
cursor = '0'
while cursor != 0:
cursor, keys = r.scan(cursor=cursor, match=f"{prefix}*", count=1000) # count 可以调整
keys_with_prefix.extend(keys)
print(f"找到 {len(keys_with_prefix)} 个以 '{prefix}' 开头的 key:")
# for key in keys_with_prefix:
# print(key.decode()) # 如果 key 是 bytes 类型,需要解码
解释:
- r.scan(cursor=cursor, match=f"{prefix}*", count=1000): 执行 SCAN 命令。cursor=cursor: 指定游标,初始为 ‘0’,后续迭代使用上次返回的游标。match=f"{prefix}*": 使用 MATCH 选项,匹配以 prefix 开头的 key。 * 是通配符。count=1000: 每次迭代尝试返回 1000 个 key (实际返回数量可能少于 1000)。
- cursor, keys = ...: SCAN 命令返回一个包含两个元素的元组:新的游标和匹配的 key 列表。
- keys_with_prefix.extend(keys): 将本次迭代返回的 key 添加到结果列表中。
- while cursor != 0:: 循环直到游标返回 ‘0’,表示迭代完成。
2. 使用 SSCAN (如果前缀 key 存储在 Set 中 - 间接方法)
如果你的前缀 key 实际上是存储在一个 Set 数据结构中 (例如,你维护了一个 Set 专门用来索引所有以特定前缀开头的 key),那么可以使用 SSCAN 命令迭代 Set 中的成员。
- 优点:非阻塞: SSCAN 也是非阻塞的。更高效 (如果 Set 结构合理): 如果 Set 中只包含前缀 key,那么 SSCAN 会比 SCAN 在整个 key 空间中搜索更高效。
- 缺点:需要预先维护 Set 结构: 你需要额外维护一个 Set 来存储前缀 key,这增加了写入操作的复杂性。间接方法: 不是直接查找 key,而是查找 Set 中的成员,需要额外的步骤来维护 Set。
- 适用场景: 如果你已经有或可以维护一个 Set 来索引前缀 key,并且需要频繁查找,这种方法可能更高效。
示例 (假设你有一个 Set 叫做 prefix_keys_set 存储了所有以 “your_prefix:” 开头的 key):
python复制代码import redis
r = redis.Redis(host='localhost', port=6379, db=0)
prefix_keys_set_name = "prefix_keys_set" # 假设你的 Set 名称
keys_with_prefix = []
cursor = '0'
while cursor != 0:
cursor, keys = r.sscan(prefix_keys_set_name, cursor=cursor, count=1000)
keys_with_prefix.extend(keys)
print(f"从 Set '{prefix_keys_set_name}' 中找到 {len(keys_with_prefix)} 个 key:")
# for key in keys_with_prefix:
# print(key.decode())
注意: 你需要自行维护 prefix_keys_set 这个 Set。 在每次创建以该前缀开头的 key 时,需要将其添加到 Set 中;在删除 key 时,需要从 Set 中移除。 这通常需要使用事务或 Lua 脚本来保证原子性。
3. 使用 RedisSearch 模块 (如果安装了 RedisSearch)
如果你的 Redis 服务器安装了 RedisSearch 模块,这是一个更强大的选择,可以进行更复杂的搜索,包括前缀搜索、模糊搜索、全文搜索等。
- 优点:高性能: RedisSearch 专门为搜索优化,性能很高。功能强大: 支持多种搜索类型,包括前缀搜索。索引: RedisSearch 会创建索引,加速搜索。
- 缺点:需要安装 RedisSearch 模块: 不是 Redis 内置功能,需要额外安装和配置。学习成本: 需要学习 RedisSearch 的语法和使用方法。
- 适用场景: 如果你的应用需要更复杂的搜索功能,或者对性能要求非常高,并且可以安装 RedisSearch 模块,这是一个很好的选择。
示例 (使用 RedisSearch 的 FT.SEARCH 命令):
python复制代码import redis
r = redis.Redis(host='localhost', port=6379, db=0)
# 假设你已经创建了一个名为 "my_index" 的 RedisSearch 索引
index_name = "my_index"
prefix = "your_prefix:"
# 使用 FT.SEARCH 命令进行前缀搜索
result = r.ft(index_name).search(f"@{prefix}*") # 注意语法可能需要根据 RedisSearch 版本调整
print(f"使用 RedisSearch 找到 {result.total} 个以 '{prefix}' 开头的 key:")
# for i in range(0, result.total):
# key = result.docs[i].id
# print(key)
注意: 使用 RedisSearch 前,你需要先创建索引,并确保你的 key 被索引到。 索引的创建和数据导入是 RedisSearch 使用的关键步骤。
4. 绝对 不要 使用 KEYS prefix*
- 原因: KEYS 命令会阻塞 Redis 服务器,因为它需要遍历整个 key 空间。 在拥有 1 亿个 key 的情况下,这将是一个非常耗时的操作,会导致 Redis 响应缓慢甚至停止响应,严重影响生产环境。
总结和建议:
- 对于大多数情况,最推荐使用 SCAN 命令。 它安全、非阻塞,并且可以有效地找到以特定前缀开头的 key。
- 如果性能是极致追求,并且可以维护额外的 Set 结构,可以考虑使用 SSCAN 结合 Set 索引。 但需要仔细权衡维护 Set 的成本和收益。
- 如果需要更强大的搜索功能,并且可以安装 RedisSearch 模块,RedisSearch 是一个非常好的选择。 它提供了高性能和丰富的功能。
- 坚决避免使用 KEYS prefix* 命令,尤其是在生产环境中。
选择哪种方法取决于你的具体需求、Redis 环境和性能要求。 SCAN 通常是最佳的通用解决方案。 在选择任何方法之前,都建议在测试环境中进行充分的性能测试,以确保选择的方法适合你的应用场景。
相关推荐
- Spring Boot3 连接 Redis 竟有这么多实用方式
-
各位互联网大厂的后端开发精英们,在日常开发中,想必大家都面临过系统性能优化的挑战。当系统数据量逐渐增大、并发请求不断增多时,如何提升系统的响应速度和稳定性,成为了我们必须攻克的难题。而Redis,这...
- 隧道 ssh -L 命令总结 和 windows端口转发配置
-
摘要:隧道ssh-L命令总结和windows端口转发配置关键词:隧道、ssh-L、端口转发、网络映射整体说明最近在项目中,因为内网的安全密级比较高,只能有一台机器连接内网数据库,推送...
- 火爆BOOS直聘的13个大厂Java社招面经(5年经验)助你狂拿offer
-
火爆BOOS直聘的13个大厂Java社招面经(5年经验)助你狂拿offer综上所述,面试遇到的所有问题,整理成了一份文档,希望大家能够喜欢!!Java面试题分享(Java中高级核心知识全面解析)一、J...
- 「第五期」游服务器一二三面 秋招 米哈游
-
一面下午2点,35分钟golang内存模型golang并发模型golanggc原理过程channel用途,原理redis数据结构,底层实现跳跃表查询插入复杂度进程,线程,协程kill原理除了kil...
- RMQ——支持合并和优先级的消息队列
-
业务背景在一个项目中需要实现一个功能,商品价格发生变化时将商品价格打印在商品主图上面,那么需要在价格发生变动的时候触发合成一张带价格的图片,每一次触发合图时计算价格都是获取当前最新的价格。上游价格变化...
- Redis 中的 zset 为什么要用跳跃表,而不是B+ Tree 呢?
-
Redis中的有序集合使用的是一种叫做跳跃表(SkipList)的数据结构来实现,而不是使用B+Tree。本文将介绍为什么Redis中使用跳跃表来实现有序集合,而不是B+Tree,并且探讨跳跃表...
- 一文让你彻底搞懂 WebSocket 的原理
-
作者:木木匠转发链接:https://juejin.im/post/5c693a4f51882561fb1db0ff一、概述上一篇文章《图文深入http三次握手核心问题【思维导图】》我们分析了简单的一...
- Redis与Java整合的最佳实践
-
Redis与Java整合的最佳实践在这个数字化时代,数据处理速度决定了企业的竞争力。Redis作为一款高性能的内存数据库,以其卓越的速度和丰富的数据结构,成为Java开发者的重要伙伴。本文将带你深入了...
- Docker与Redis:轻松部署和管理你的Redis实例
-
在高速发展的云计算时代,应用程序的部署和管理变得越来越复杂。面对各种操作系统、依赖库和环境差异,开发者常常陷入“在我机器上能跑”的泥潭。然而,容器化技术的兴起,尤其是Docker的普及,彻底改变了这一...
- Java开发中的缓存策略:让程序飞得更快
-
Java开发中的缓存策略:让程序飞得更快缓存是什么?首先,让我们来聊聊什么是缓存。简单来说,缓存是一种存储机制,它将数据保存在更快速的存储介质中,以便后续使用时能够更快地访问。比如,当你打开一个网页时...
- 国庆临近,字节后端开发3+4面,终于拿到秋招第一个offer
-
字节跳动,先面了data部门,3面技术面之后hr说需要实习转正,拒绝,之后另一个部门捞起,四面技术面,已oc分享面经,希望对大家有所帮助,秋招顺利在文末分享了我为金九银十准备的备战资源库,包含了源码笔...
- “快”就一个字!Redis凭什么能让你的APP快到飞起?
-
咱们今天就来聊一个字——“快”!在这个信息爆炸、耐心越来越稀缺的时代,谁不希望自己手机里的APP点一下“嗖”就打开,刷一下“唰”就更新?谁要是敢让咱用户盯着个小圈圈干等,那简直就是在“劝退”!而说到让...
- 双十一秒杀,为何总能抢到?Redis功不可没!
-
一年一度的双十一“剁手节”,那场面,简直比春运抢票还刺激!零点的钟声一敲响,亿万个手指头在屏幕上疯狂戳戳戳,眼睛瞪得像铜铃,就为了抢到那个心心念念的半价商品、限量版宝贝。你有没有发现一个奇怪的现象?明...
- 后端开发必看!为什么说Redis是天然的幂等性?
-
你在做后端开发的时候,有没有遇到过这样的困扰:高并发场景下,同一个操作重复执行多次,导致数据混乱、业务逻辑出错?别担心,很多同行都踩过这个坑。某电商平台就曾因订单创建接口在高并发时不具备幂等性,用户多...
- 开发一个app需要哪些技术和工具
-
APP开发需要一系列技术和工具的支持,以下是对这些技术的清晰归纳和分点表示:一、前端开发技术HTML用于构建页面结构。CSS用于样式设计和布局。JavaScript用于页面交互和逻辑处理。React...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- oracle位图索引 (63)
- oracle批量插入数据 (62)
- oracle事务隔离级别 (53)
- oracle 空为0 (50)
- oracle主从同步 (55)
- oracle 乐观锁 (51)
- redis 命令 (78)
- php redis (88)
- redis 存储 (66)
- redis 锁 (69)
- 启动 redis (66)
- redis 时间 (56)
- redis 删除 (67)
- redis内存 (57)
- redis并发 (52)
- redis 主从 (69)
- redis 订阅 (51)
- redis 登录 (54)
- redis 面试 (58)
- 阿里 redis (59)
- redis 搭建 (53)
- redis的缓存 (55)
- lua redis (58)
- redis 连接池 (61)
- redis 限流 (51)