• Redis的KEYS命令把我搞崩溃了改用SCAN才活过来

作为 Redis 的长期使用者，我一直对它的高性能和灵活性赞不绝口。只是在一次生产环境的事故中，我深刻体会到了错误使用 Redis 命令可能带来的灾难性后果。这次经历让我从 KEYS 命令的“甜蜜陷阱”中惊醒，最终通过 SCAN 命令成功解决了问题。

第一部分的观点是，KEYS 命令的致命诱惑

基本用法

KEYS pattern

其中 pattern 支持 glob‑style 通配符：

• * 匹配任意数量的任意字符
• ? 匹配单个字符
• 匹配指定字符中的一个

从例如来看。

KEYS user:* # 匹配所有以 user: 开头的键

为什么开发者喜欢 KEYS

1. 简单直观：语法简洁，符合直觉。其实，
2. 功能比较全面：支持丰富的模式匹配。
3. 即时反馈：直接返回所有匹配结果。
4. 文档示例：大量教程和官方文档都用它做示例。

我的灾难现场

在项目中，我需要统计所有以 “session:” 开头的活跃会话。说起来，自然地，我 想到的是：

KEYS session:*

- 开发环境 & 小规模数据下这条命令运行良好。- 当代码部署到生产时问题瞬间暴露。

阻塞式执行本质

`KEYS` 是阻塞命令：

1. 遍历整个键空间。
2. S​对于大型库，这可能耗费数秒甚至更久。
3. S​期间 Redis 无法处理其他请求。

`KEYS` 的时间复杂度为 O，N 为库中键总数。

生产环境影响

1. 请求超时：P​其他客户端命令排队等待。
2. 连接池耗尽：P​等待中的客户端占满所有连接。
3. A服务雪崩：P​依赖 Redis 的服务相继失效。监控告警 ：
4. Redis 延迟飙升触发警报。

h2 id ="scan-savior"> 第三部分：SCAN 命令的救赎

h ３> 基本原理 p> SCAN 在 Redis 2.8 引入。实现键空间增量遍历： pre> SCAN cursor / code> p> 关键特性： ol> li>非阻塞 ： 每次调用只返回部分结果 li>可恢复 ： 游标记录遍历状态 li>可配置 ： COUNT 调整每批返回数量 / ol>

h３> 工作方式 ol> li>首次调用 SCAN 0 开始迭代 li>返回游标 + 部分键列表 li>使用返回游标继续迭代 li>游标为 0 表示遍历完成 / ol> p 示例： pre> SCAN 0 MATCH session:* COUNT 500 / code>

h３> 为什么 SCAN 更安全 ol> li>增量式处理 ： 每次只处理一小块数据 li>可中断 ： 随时停止且不会丢失进度 li>可控内存 ： 限制每批返回键数 li>集群友好 ： 适合分布式部署 / ol>

h２ id ="best-practices"> 第四部分：深入 SCAN 的常用方法

h３ COUNT 参数调优 p COUNT 决定每轮返回多少键： ul> li>太小 → 增加网络往返次数 li>太大 → 仍可能导致延迟峰值 / ul> p 建议步骤： ol> li>从 100‑500 开始测试 li>监控 Redis 延迟指标 li>根据实际数据分布微调 / ol>

h３ 处理重复键的问题 p 因为迭代期间键空间可能变化，SCAN 有可能返回重复键。p 方法： ol> li>客户端去重 li>业务容忍少量重复 / ol>

h３ 集群环境中的使用 p 在 Redis 集群里需要对每个节点单独执行 SCAN。p 示例： pre> redis-cli --cluster call SCAN 0 MATCH pattern COUNT 1000 / code>

h３ 编程语言实现示例 pre> def scan_keys: cursor = '0' keys = while True: cursor,part = r.scan keys.extend if cursor == '0': break return keys / code>