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

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

---

引言

作为Redis的长期用户，我一直对它的高性能和灵活性赞不绝口。然而，在一次生产环境的事故中，我深刻体会到了错误使用Redis命令可能带来的灾难性后果。这次经历让我从KEYS命令的"甜蜜陷阱"中惊醒，最终通过SCAN命令成功解决了问题。本文将详细分享这次教训，深入分析KEYS的问题根源，并探讨SCAN命令的正确使用方式。

第一部分：KEYS命令的致命诱惑

1.1 KEYS命令的基本用法

KEYS命令是Redis中最直观的模式匹配命令，语法简单明了：

KEYS pattern

其中pattern支持glob-style的通配符：

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

例如：

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

1.2 为什么开发人员喜欢KEYS

KEYS命令受到开发者青睐有几个原因：

1. 简单直观：语法简单，符合直觉
2. 功能强大：支持丰富的模式匹配
3. 即时反馈：直接返回所有匹配结果
4. 文档示例：很多教程和文档都用KEYS做示例

1.3 我的灾难现场

在我的案例中，我需要统计所有以"session:"开头的活跃会话。自然地，我首先想到的是：

KEYS session:*

在开发环境和小规模数据下，这个命令运行良好。但当我们将代码部署到生产环境时（一个包含数千万键的Redis集群），问题开始显现。

第二部分：KEYS命令的致命缺陷

2.1 阻塞式执行的本质

KEYS命令的最大问题是它是阻塞式的：

1. 执行KEYS时，Redis会遍历整个键空间
2. 对于大型数据库，这可能花费数秒甚至更长时间
3. 在此期间，Redis无法处理其他命令

2.2 时间复杂度分析

KEYS命令的时间复杂度是O(N)，其中N是数据库中键的总数。对于有1000万键的数据库：

• 假设Redis每秒能扫描100万键
• 一次KEYS操作需要约10秒的阻塞时间

2.3 生产环境的影响

在我们的案例中，KEYS命令导致了：

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

第三部分：SCAN命令的救赎

3.1 SCAN命令的基本原理

Redis 2.8引入了SCAN命令，提供了键空间的可迭代遍历：

SCAN cursor [MATCH pattern] [COUNT count]

关键特性：

1. 非阻塞：每次调用只返回部分结果
2. 可恢复：使用游标记录遍历状态
3. 可配置：通过COUNT调整每次返回数量

3.2 SCAN的工作机制

1. 首次调用SCAN 0开始迭代
2. 返回一个游标和部分键列表
3. 使用返回的游标继续迭代
4. 游标返回0表示迭代完成

示例：

SCAN 0 MATCH session:* COUNT 100

3.3 为什么SCAN更安全

1. 增量式处理：每次只处理部分数据
2. 可中断：可以随时停止而不丢失进度
3. 可控内存：限制每次返回的键数量
4. 集群友好：适合分布式环境

第四部分：深入SCAN的最佳实践

4.1 COUNT参数的调优

COUNT参数影响每次迭代返回的键数量：

• 太小：增加网络往返次数
• 太大：仍可能造成延迟

建议：

1. 从100-500开始测试
2. 监控Redis的延迟指标
3. 根据实际数据分布调整

4.2 处理重复键的问题

SCAN可能会返回重复的键，因为：

1. 键空间可能在迭代期间变化
2. Redis使用哈希桶的遍历方式

解决方案：

1. 客户端去重
2. 容忍少量重复（如果业务允许）

4.3 在集群环境中的使用

在Redis集群中，需要注意：

1. 每个节点需要单独SCAN
2. 使用--cluster选项的redis-cli：

redis-cli --cluster call <host:port> SCAN 0 MATCH pattern COUNT 100

4.4 编程语言中的实现示例

Python示例：

def scan_keys(pattern, count=100):
    cursor = '0'
    keys = []
    while cursor != 0:
        cursor, partial_keys = redis.scan(
            cursor=cursor, 
            match=pattern, 
            count=count
        )
        keys.extend(partial_keys)
    return keys

第五部分：其他替代方案

5.1 维护专门的索引集合

对于频繁查询的模式：

1. 使用Set维护匹配的键
2. 写入时同步更新索引
3. 查询时直接使用SMEMBERS

5.2 Redisearch模块

如果需要复杂的搜索功能：

1. 支持高级查询语法
2. 提供全文搜索能力
3. 需要额外内存开销

5.3 数据分片策略

通过设计键结构：

1. 将数据分散到多个键前缀
2. 避免需要全量扫描
3. 例如：按用户ID或日期分片

第六部分：性能对比测试

6.1 测试环境

• Redis 6.2
• 1000万测试键
• 其中50万匹配"session:*"模式
• 8核CPU，16GB内存服务器

6.2 KEYS命令结果

127. 0.0.1:6379> KEYS session:*
(耗时 4.82秒)

6.3 SCAN命令结果(COUNT=100)

127. 0.0.1:6379> SCAN 0 MATCH session:* COUNT 100
(每次调用耗时 5-15ms，共需要约5000次调用)

6.4 系统资源对比

指标	KEYS	SCAN
最大延迟	4820ms	15ms
内存峰值	1.2GB	10MB
CPU使用率	100%	<5%

第七部分：经验教训与总结

7.1 关键教训

1. 不要在生产环境使用KEYS：无论数据量大小
2. 了解命令的时间复杂度：阅读官方文档的复杂度说明
3. 测试环境的局限性：小数据量无法暴露性能问题

7.2 何时可以使用KEYS

唯一安全的使用场景：

1. 调试目的的redis-cli交互
2. 确定不会有并发访问
3. 数据量极小的环境

7.3 监控与告警建议

1. 监控慢查询日志
2. 设置命令执行时间阈值
3. 定期审查代码中的Redis命令

结语

从KEYS到SCAN的转变，不仅是命令的替换，更是对Redis工作原理的深入理解。这次经历让我明白，在分布式系统和高并发环境中，每个技术决策都需要考虑其系统性影响。希望本文的分享能帮助你避免类似的陷阱，让你的Redis使用更加稳健高效。