必须禁用keys改用scan，因keys会单线程阻塞redis导致服务假死，而scan通过游标分批迭代、非阻塞、支持match前缀过滤，是生产环境唯一安全解法。
直接禁用 KEYS，改用 SCAN + MATCH 分批迭代，是唯一安全解法。这不是“优化建议”，而是生产环境的硬性准入条件——只要允许 KEYS 执行，哪怕只在后台管理页藏一条 redisTemplate.keys("user:*")，就等于在 Redis 主线程上埋了雷。
为什么 KEYS * 会瞬间假死 Redis
Redis 是单线程处理命令的。KEYS 不是“查得慢”，是“全程霸占主线程”：它必须遍历整个键空间（底层 dict 或 zipmap），对每个 key 做字符串匹配，期间无法响应任何其他请求。50 万 key 可能卡住 200ms，500 万 key 就可能卡 2s+。所有客户端连接排队、超时、连接池打满、主从心跳中断，监控告警会连环触发。
常见错误现象包括：
- 接口大面积
timeout，但 Redis CPU 和内存指标看起来“一切正常” -
SLOWLOG里反复出现KEYS，耗时几百毫秒到几秒不等 - 运维执行
KEYS user:123*后，业务同学立刻反馈登录失败、订单提交卡顿
怎么用 SCAN 安全替代 KEYS
SCAN 不是“换个命令就行”，它需要客户端配合游标循环。核心参数只有三个：cursor、MATCH、COUNT。
-
COUNT不是“返回数量保证”，而是服务端每次扫描哈希槽的大致数量，建议设为100～500；设太大（如10000）会让单次调用变慢，甚至进SLOWLOG - 必须用游标循环直到返回
cursor = "0"，否则漏 key；示例：SCAN 0 MATCH "order:2024*" COUNT 200→ 拿到新cursor→ 再发SCAN <new_cursor> MATCH ...</new_cursor> -
MATCH过滤发生在服务端，不是客户端拉回再筛，所以网络开销小，但通配符不能太宽（如*仍会扫全库，只是分批）
生产环境必须做的三件事
光会写 SCAN 不够，得让风险真正落地可控：
- 在
redis.conf中配置rename-command KEYS ""，彻底禁用该命令（Redis 6.0+ 默认支持） - 云 Redis 实例（如阿里云 Tair、腾讯云 CRS）通常已默认屏蔽
KEYS *，但需确认是否允许KEYS pattern—— 一律禁用 - 代码层拦截：Spring Boot 项目可在
RedisTemplate外包一层，对keys()方法抛异常或打告警日志；Java 用 Jedis 的话，可重写execute()拦截KEYS命令字
容易被忽略的细节
SCAN 虽然不阻塞，但它不是“零代价”。如果在高并发时段密集发起多个 SCAN（比如 10 个后台任务同时扫不同前缀），仍会累积 CPU 开销，导致延迟毛刺。更隐蔽的是：SCAN 不保证一次遍历能拿到全部 key（有新增/删除时可能重复或遗漏），所以它适合“运营排查”“缓存清理”这类非强一致性场景，**绝不能用于依赖“完整结果”的业务逻辑**（比如导出全量用户列表）。真要强一致，得靠业务层加锁 + 计数器 + 分片 key 设计，而不是指望 Redis 命令本身。
