上周我把一台Redis实例的key数量从680万压到了180万。这个数字放在大厂可能不值一提，但在我们这种核心业务全挤在一台8G内存实例上的场景里，680万个key已经快到临界点了——每次执行一条慢命令，CPU就往上蹿，业务方在群里问“缓存服务是不是又抽风了”。更尴尬的是，很多key回头看根本不知道该不该删，因为光看名字你永远判断不出它背后是哪个业务在写、什么时候写的。
后来我换了一个思路：让DeepSeek来当我的结对程序员，帮我写一组Shell脚本，把“找出无用key、批量删除、给剩余key补设TTL”这套流程自动化。折腾了两个晚上，方案终于完整跑通。今天把这套完整方案、脚本和踩过的坑都摊开讲，给正在被key数量压得喘不过气的朋友一个参考。
这篇文章适合谁？后端工程师、运维、SRE，以及所有在用Redis但没系统性做过缓存治理的团队。内容不聊高深理论，全是实操：key数量为什么会爆炸、为什么我选Shell而不是Python/Go、DeepSeek怎么辅助写脚本、完整的SCAN+UNLINK清理流程、批量设置TTL的办法，以及我实实在在踩过的坑。
1. key数量暴增，到底影响了Redis的什么
1.1 内存开销：你删掉的不是“几个key”，是“一份份元数据”
很多人对Redis内存的认知停留在“value有多大就占多大空间”，实际上每个key本身还带一整套元数据。Redis底层是一个dict字典结构，每个key对应一个dictEntry，里面存了key的指针、value的指针、哈希表next指针，再加上redisObject对象头、SDS字符串头等等。一个空的String类型key，哪怕value只有一个字节，真实占用的内存也可能在70字节以上。
我粗略算过一笔账：如果5百万个无意义的key，平均key名30字节、value是“1”这种短字符串，每个key整体占用按90字节算，光key这一层就是450MB。这就是为什么有些Redis实例存的数据不多，RSS却高得吓人。
这里也顺带解释一个大家常问的点：为什么不用Hash结构优化？如果你有大量同前缀的key，比如user:1001:name、user:1001:age，把同一批uid下面的字段塞进一个Hash里，用hset user:1001 name "xxx"、hset user:1001 age 20，元数据开销就能被多个字段摊薄。Redis在内部对小Hash还有ziplist/listpack压缩编码，内存收益非常明显。但改造数据结构的成本不是一篇文章能讲完的，今天的主角还是“清理”。
1.2 操作延迟与阻塞风险：慢命令才是致命伤
key数量一多，最明显的就是KEYS命令不能碰。KEYS *要对整个字典做全量遍历，几百万key时，执行一次直接阻塞Redis好几秒，期间所有读写请求全部排队，业务直接雪崩。
就算不用KEYS，key数量过大也会遇到其他隐性成本：
- RDB持久化要遍历全部key，AOF重写也一样，key越多，后台保存耗时越长，fork出来的子进程如果内存没释放干净，写时复制带来的内存增长更吓人。
- 主从复制时，全量同步要传输RDB文件，key数量直接决定RDB文件大小，同步时间会翻倍。
- 集群模式下，key数量影响slot迁移速度，不过单机场景暂时不涉及。
redis-cli --bigkeys这类分析工具要遍历整个keyspace，key越多，跑完一轮越久。
我那次遇到的实际现象是：实例的CPU经常莫名其妙飙到80%以上，排查发现并没有慢查询日志，后来才发现是后台RDB保存周期变长，加上内存碎片率一直维持在1.5左右，整个实例的状态就很“黏”。
1.3 业务与运维成本：你无法回答“这个key该不该删”
key数量爆炸最隐蔽的问题，是它让所有人失去了判断力。INFO keyspace一查，keys几百万，expires却只有一小部分，你再问开发“这些key是不是都能删”，没人敢打包票。数据保留时间不可控，安全审计过不了，故障复盘说不清，最后只能继续堆内存。
所以Redis缓存治理的第一个动作永远是盘点：你到底存了哪些前缀、哪些有TTL、哪些没有。这一步搞清楚了，后面删key才有底气。
2. 方案选型：为什么我用Shell脚本而不是其他工具
2.1 redis-cli已经够强，只是很多人没用对
坦白说，清理Redis key这件事，Redis官方自带的redis-cli已经覆盖了90%的需求。关键是你会不会组合它：
redis-cli --scan --pattern 'temp:*' --count 500：按模式增量遍历，不阻塞实例。redis-cli --scan | while read key; do ...; done：把扫描结果接到Shell循环里做流式处理。redis-cli --pipe < file：把一批Redis协议命令一次性写入，性能比一条条执行高一个量级。redis-cli --bigkeys：粗略分析大key分布。redis-cli --rdb：把RDB备份拉回本地。
Shell脚本的定位就是把这些命令串起来，补齐日志、灰度开关、参数校验这些事。需要依赖吗？不需要。redis-cli装好，bash自带，任何一台服务器都能跑。这比Python脚本需要装redis-py、Go脚本需要交叉编译要轻太多。
2.2 为什么我不推荐一上来就写Python/Go
不是说Python不行，而是“清理key”这种一次性或低频任务，用Shell脚本有天然优势：
- 零依赖，交付就是单个
.sh文件，扔到服务器上直接执行。 - 可以扔进crontab，配合
flock做防重入，运维同学看一眼就懂。 - 出了问题，直接看日志和退出码，不需要另起一套运行环境。
当然，如果你有几十亿key、需要做复杂的容量预估和动态调整，那确实该上Python或者Go。但在大多数中小团队里，Shell脚本足够，而且最小可行。
2.3 DeepSeek在里面的角色：不是替你写，而是帮你把手册翻明白
这次我用DeepSeek的方式比较特殊：我不要求它一次性生成最终脚本，而是把它当“Redis活手册 + 代码审查员”。我把自己要做的事说清楚，让它先给一个能跑的版本，然后我指着代码里的问题逐条问，它再改。
比如我问它“SCAN返回的cursor怎么在Shell里处理”，它会告诉我redis-cli scan 0 MATCH xxx COUNT 200的输出格式，还会提醒我cursor在循环里更新的写法。老实说，这些知识网上都能查到，但DeepSeek能顺着我的上下文连续给出方案，省掉了我翻文档的时间。
3. 用DeepSeek辅助生成清理脚本的全过程
3.1 第一轮Prompt：把约束条件说清楚
我给的Prompt大概是这样的：
我有一台Redis实例，key数量约600万，有问题的key主要是这几个前缀： - session:xxx，会话缓存，可以删 - temp:xxx，临时数据，超过24小时就没用了 - login_code:xxx，登录验证码，超过10分钟就没用 要求： 1. 写一个bash脚本，扫描指定前缀的key 2. 必须用SCAN，不能用KEYS，避免阻塞 3. 删除时用UNLINK，避免删除大key时阻塞 4. 支持--dry-run参数，只打印不执行 5. 输出日志，记录扫描数量和删除情况 6. 一次扫描一坨key，不要一条条删除，尽量高效这个Prompt的信息量已经够了。DeepSeek第一版生成的东西，其实是一个比较常见的“扫描+删除”脚本，核心逻辑是用redis-cli --scan收集key，然后用xargs分批调redis-cli unlink。能用，但有很多隐患。
3.2 DeepSeek生成的第一版脚本长什么样
简化后大概是这样的：
#!/bin/bash redis-cli -h 127.0.0.1 -p 6379 --scan --pattern "session:*" | xargs -n 200 redis-cli -h 127.0.0.1 -p 6379 unlink看着没问题？问题刚好就藏在细节里：
--scan会把所有匹配key都读到内存里，如果匹配到500万个key，这串输出会非常长，虽说不像KEYS那样阻塞Redis，但客户端Pipeline堆积也可能造成瞬时压力。xargs -n 200 redis-cli unlink每200个key起一个redis-cli进程，5百万key就是2.5万个进程，光进程调度开销就够喝一壶。- 没有日志，没有dry-run，出问题很难回滚。
- 如果key名里有空格或特殊字符，
xargs的默认空白分割会把一个key拆成两截，严重的话会删错东西。
我没有直接跑这个版本，而是让它按“协议文件 + --pipe”的方式重写，一次连接把批量UNLINK发完。
3.3 迭代后的最终脚本：SCAN + RESP协议 + --pipe
最终版本我用的是“扫描结果写入临时文件 + 构造RESP协议 + 管道发送”的方式，兼顾了效率和可观测性：
#!/bin/bash # ============================================================ # redis_clean_keys.sh # 基于 SCAN + UNLINK 批量清理 Redis key # # 用法: # ./redis_clean_keys.sh -h 127.0.0.1 -p 6379 -n 0 -P "session:*" --dry-run # ./redis_clean_keys.sh -h 127.0.0.1 -p 6379 -n 0 -P "session:*" # # 依赖: redis-cli, date, sed, awk # ============================================================ set -uo pipefail HOST="127.0.0.1" PORT="6379" DB="0" PASSWORD="" PATTERN="" BATCH="200" DRY_RUN=0 LOG_FILE="redis_clean_$(date +%Y%m%d_%H%M%S).log" log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG_FILE" } usage() { cat <<EOF Usage: $0 [options] Options: -h, --host <host> Redis 地址，默认 127.0.0.1 -p, --port <port> Redis 端口，默认 6379 -n, --db <number> Redis 库号，默认 0 -a, --password <pwd> Redis 密码 -P, --pattern <pattern> 需要匹配的 key 前缀/模式（必填） -b, --batch <number> SCAN 每次遍历的数量，默认 200 --dry-run 只输出将要删除的 key，不真正执行 EOF exit 1 } while [[ $# -gt 0 ]]; do case "$1" in -h|--host) HOST="$2"; shift 2;; -p|--port) PORT="$2"; shift 2;; -n|--db) DB="$2"; shift 2;; -a|--password) PASSWORD="$2"; shift 2;; -P|--pattern) PATTERN="$2"; shift 2;; -b|--batch) BATCH="$2"; shift 2;; --dry-run) DRY_RUN=1; shift;; *) echo "未知参数: $1"; usage;; esac done if [[ -z "$PATTERN" ]]; then echo "错误: 必须通过 -P 指定 key 匹配模式" usage fi AUTH_ARGS=() if [[ -n "$PASSWORD" ]]; then AUTH_ARGS=("-a" "$PASSWORD") fi SCAN_BASE=(redis-cli -h "$HOST" -p "$PORT" -n "$DB" "${AUTH_ARGS[@]}") SCAN_FILE=$(mktemp) PROTO_FILE=$(mktemp) trap 'rm -f "$SCAN_FILE" "$PROTO_FILE"' EXIT log "开始扫描 pattern=$PATTERN batch=$BATCH ..." "${SCAN_BASE[@]}" --scan --pattern "$PATTERN" --count "$BATCH" > "$SCAN_FILE" 2>>"$LOG_FILE" SCANNED=0 while IFS= read -r key; do SCANNED=$((SCANNED + 1)) if [[ $DRY_RUN -eq 1 ]]; then log "[DRY RUN] 将删除: $key" else printf "*2\r\n\$6\r\nUNLINK\r\n\$%d\r\n%s\r\n" "${#key}" "$key" >> "$PROTO_FILE" fi done < "$SCAN_FILE" log "本次扫描到 $SCANNED 个匹配 key" if [[ $DRY_RUN -eq 0 && -s "$PROTO_FILE" ]]; then log "开始通过 --pipe 批量 UNLINK ..." "${SCAN_BASE[@]}" --pipe < "$PROTO_FILE" >> "$LOG_FILE" 2>&1 fi log "清理任务执行完毕"这段脚本的几个关键点：
mktemp生成临时文件，trap确保脚本异常退出时也能清理临时文件。- 用
--scan --count $BATCH控制每轮遍历的抓取量，给服务端一个“降低单次耗时”的提示。 - 删除命令不直接用字符串拼接，而是按RESP协议生成
UNLINK key，这样即使key名里有空格、引号也不会出问题。 --dry-run只在日志里打印，不碰线上数据。
跑一个dry-run，你会看到类似输出：
[2025-03-02 02:11:32] 开始扫描 pattern=session:* batch=200 ... [2025-03-02 02:11:41] 本次扫描到 312405 个匹配 key [2025-03-02 02:11:41] [DRY RUN] 将删除: session:1:a [2025-03-02 02:11:41] [DRY RUN] 将删除: session:1:b ...这个日志本身就是很珍贵的资产，它告诉你这个pattern下到底有多少key、都是谁。
3.4 我让DeepSeek继续审查：它确实发现了我容易漏掉的问题
脚本能跑之后，我又问了DeepSeek几个问题：
“如果Redis密码里有特殊字符怎么办？”“如果SCAN_FILE里的key数量特别大，临时文件会不会撑爆磁盘？”“--pipe返回ERR Protocol error: invalid multibulk length通常是啥原因？”
它一一给了答案。尤其有一条提醒比较有价值：redis-cli --pipe不会自动判断每条命令是否执行成功，它只统计errors数量，所以脚本结束后至少要看一眼日志里的errors: 0，别想当然以为全删了。
这一点我以前确实踩过坑，之前的清理脚本跑完显示“5万个key已删除”，结果Redis里还剩几万个，因为中途有某个key因为类型原因报错了，而我没看错误计数。
4. 完整实操：从盘点、清理到设置TTL的落地方式
4.1 第一步：先盘点，别急着删
所有清理动作开始之前，先回答两个问题：现在有哪些前缀？每个前缀有多少key？
最直接的方式是先用INFO keyspace看整体：
redis-cli -h 127.0.0.1 -p 6379 -n 0 info keyspace输出里能看到keys=和expires=，如果keys很多、expires很少，说明大量key没有过期时间，这是最大的风险点。
然后按前缀统计分布。我当时的做法是扫描全部key，用冒号切出第一段，统计频次：
redis-cli -h 127.0.0.1 -p 6379 -n 0 --scan --count 1000 | awk -F: '{print $1}' | sort | uniq -c | sort -rn | head -20输出大概长这样：
245833 session 152100 temp 89102 login_code 55100 user 12600 cart_ 322 unknown_prefix这一步花不了几分钟，但对整个清理方案至关重要。你会清楚看到哪个前缀是“大头”，哪个可能是历史遗留。
另外，强烈建议跑一次redis-cli --bigkeys，虽然它不会直接告诉你该删哪些key，但能帮你找出那些“删除代价很高”的大key：
redis-cli -h 127.0.0.1 -p 6379 -n 0 --bigkeys如果发现某些key是几MB甚至几十MB的Hash或List，你就得额外小心，后面我们会说到大key的删除策略。
4.2 第二步：按前缀批量清理
盘点完，就到了主角登场的时候。
假设我们发现temp:前缀下有一大批24小时前的临时数据，可以这么操作：
先dry-run，看看匹配到的key数量是否符合预期：
./redis_clean_keys.sh -h 127.0.0.1 -p 6379 -n 0 -P "temp:*" --dry-run确认数量和pattern没写错之后，去掉--dry-run正式清理：
./redis_clean_keys.sh -h 127.0.0.1 -p 6379 -n 0 -P "temp:*"执行完了，立刻用DBSIZE看当前库的key总数：
redis-cli -h 127.0.0.1 -p 6379 -n 0 dbsize如果清理成功，数字应该明显下降。
这里我再强调一次：清理动作一定要放在业务低峰期，并且最好提前备份RDB。我习惯在清理前先执行redis-cli --rdb /tmp/redis_backup_$(date +%s).rdb把当前数据拉到本地，防止删错后无法恢复。
4.3 第三步：给剩余key补设合理的TTL
删完一批之后，最怕的就是“清了又满”。如果你的业务代码里大量写key时没设过期时间，清理得再勤也白搭。所以第三步是给那些一直没TTL的key补上过期时间。
我当时写了一个简化版脚本，逐个判断key的TTL：
#!/bin/bash # add_ttl_without_expire.sh # 给 Redis 中没有 TTL 的 key 设置随机过期时间（12-24小时之间） redis-cli -h 127.0.0.1 -p 6379 -n 0 --scan --count 500 | while IFS= read -r key; do ttl=$(redis-cli -h 127.0.0.1 -p 6379 -n 0 ttl "$key") if [[ "$ttl" == "-1" ]]; then expire_sec=$((RANDOM % 43200 + 43200)) redis-cli -h 127.0.0.1 -p 6379 -n 0 expire "$key" "$expire_sec" >/dev/null echo "[$(date '+%Y-%m-%d %H:%M:%S')] set expire $key -> $expire_sec" >> /tmp/ttl_fix.log fi done注意，这个脚本是“一条key一次TTL查询”，性能不算好，如果你有几十万key，跑完可能要几十分钟。我的建议是：
- 先扫出没有TTL的key数量，量不大再跑这个脚本。
- 量大的话，优先修代码，让业务侧在写入时带上
EX或PX参数，从源头解决问题。 - 设置过期时间时加一个随机偏移量（我这里用的是12-24小时），避免大量key在同一秒过期引发缓存雪崩。这是生产环境的常识，但特别容易忘。
4.4 第四步：把清理和TTL巡检挂到计划任务
人工跑一次只能解决一时的问题，要持续控制key数量，最好把巡检脚本挂到crontab里。
我用的方式是在原脚本外面包一层shell，加上flock锁避免任务重叠：
#!/bin/bash # cleanup_cron.sh LOCK_FILE="/tmp/redis_cleanup.lock" # -n 表示拿不到锁就直接退出，避免上一轮任务还没跑完又启动一轮 flock -n "$LOCK_FILE" -c "/opt/scripts/redis_clean_keys.sh -h 127.0.0.1 -p 6379 -n 0 -P 'temp:*'"然后在crontab里：
# 每天凌晨3点清理临时key 0 3 * * * /opt/scripts/cleanup_cron.sh >> /tmp/redis_cleanup_cron.log 2>&1这样至少能把“临时前缀”这类明确可删的key控制住。至于那些没有TTL的key，我建议每周跑一次4.3里的巡检，把告警接上，一旦发现某类前缀的key数量异常增长，就说明业务代码有新的地方漏了设置过期时间。
5. 避坑指南：我在清理过程中踩过的坑
5.1 千万别用KEYS命令，哪怕只是“看一眼”
我知道你肯定听过这句话，但犯这个错的人依然很多。我身边就有人为了图省事，直接redis-cli keys "*" | wc -l统计key数量，结果几百万key的实例瞬间卡住，线上请求超时。
统计key数量请用DBSIZE，扫描特定pattern请用--scan。KEYS唯一适用场景是本地开发环境或者key数量极少的测试实例。
5.2 大key别直接DEL，要用UNLINK
Redis 4.0之后，UNLINK就是用来替代DEL处理大key的。DEL是同步释放内存，如果value是一个几十MB的List，删除操作会阻塞实例；UNLINK会把释放内存的动作丢给后台线程，主线程很快返回。
所以我在清理脚本里特意使用了UNLINK而不是DEL。如果你匹配到的key里有Hash、List、Set、ZSet这种容器，而且体积很大，这点尤其关键。
如果你发现某个超大Hash特别碍事，又还想保留一部分数据，那可以用HSCAN加HDEL配合删，而不是一把梭：
redis-cli -h 127.0.0.1 -p 6379 -n 0 hscan big_hash_key 0 COUNT 200 | \ while read -r field; do redis-cli -h 127.0.0.1 -p 6379 -n 0 hdel big_hash_key "$field" done5.3 Redis的MATCH pattern不是正则，是glob
这个坑我用DeepSeek写脚本时也被提醒过。Redis的MATCH支持三种通配符：
*：任意长度字符?：单个字符[...]：括号内的任意一个字符
不支持+、^、[a-z]范围之外的复杂正则规则。更坑的是，*会匹配任意字符，所以user:*也能匹配到user:1:name:extra。如果你只想匹配user:后面只带一层ID的key，靠Redis的MATCH做不到，得在Shell里二次过滤。
我当时的处理方式是对照日志逐条看，确保没有误杀。如果你有类似的强过滤需求，可以先用grep -E或awk再筛一层：
redis-cli --scan --pattern "user:*" | grep -E '^user:[0-9]+$'5.4 删除后Redis内存没有立刻下降，别慌
我在清理完第一批key后发现，INFO memory里的used_memory确实降了，但used_memory_rss几乎没动，心里一沉。后来才明白，这是内存碎片和后台释放机制在捣乱。
UNLINK虽然是异步释放，但内存碎片率（mem_fragmentation_ratio）不会因为你删了key就马上恢复正常，尤其在高并发写入过的实例里，内存页散布得非常碎。RSS可能在高位维持一段时间。
遇到这种情况，我的建议是：
- 不要马上重启，先观察一段时间，后台线程会慢慢回收。
- 如果碎片率长期高于1.5，可以在维护窗口用
MEMORY PURGE尝试整理，但效果因内存分配器而异。 - 内存依然不够用，再考虑主从切换、重启或扩容。
5.5 删除后key又出现了，问题不在Redis而在上游
用脚本清完以后，如果过了一天DBSIZE又涨回原来的量级，基本可以断定有业务代码在持续写入这些key。这时候最忌讳的是“再加一条更狠的定时清理任务”，因为这是拿运维手段掩盖代码缺陷。正确做法是：
- 在Redis客户端或者业务侧给这些key统一加上TTL。
- 查一下哪些服务在写这些前缀，把缓存写入逻辑改成“写入时设置过期时间”。
- 如果实在没法改代码，至少把清理频率调高，但一定要评估是否会造成误删。
6. 常见问题与排查技巧实录
我整理了一份问题速查表，这些都是实践里被问过最多的问题：
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
redis-cli --scan --pattern 'a:*'扫到的key比实际少 | SCAN的count是一个“提示值”，服务端不一定精确返回这么多；加上遍历过程中可能有key被删除或新写入 | 多跑几轮对比，或直接在业务低峰期全量扫 |
| 执行清理脚本后Redis仍有大量同名前缀key | 业务代码在持续写入，清理速度赶不上写入速度 | 优先修业务侧TTL，再考虑提高清理频率 |
--pipe返回ERR Protocol error: invalid multibulk length | 协议文件格式被破坏，通常是key名内包含\r\n或二进制字符 | 清理前先对key名做校验，或改用--scan --quoted配合解析 |
| 清理后内存碎片率很高 | 大量key删除后内存页碎片化 | 观察自动回收，必要时维护窗口重启 |
| 脚本在crontab里重复执行 | 上一个任务没跑完，新任务又启动了 | 用flock -n做互斥锁 |
| 删除时发现部分key是其他业务正在用的线上数据 | 清理前没做充分盘点，或pattern写得太宽 | 严格遵守“先dry-run、再小批量灰度、最后全量”的流程 |
| 清理后线上出现缓存穿透 | 删得太猛，或者TTL设置太短，大量请求同时打到数据库 | TTL设置随机偏移，避免集中过期 |
最后一个关于“缓存穿透”的问题，我觉得值得多说两句。很多人清理Redis的时候，眼睛里只盯着“key减了没有”，却忽略了这些key是不是还有流量在访问。如果某个key刚被删，下一秒用户又访问了，并且业务层没有做空值缓存，那它就是一次DB硬查询。所以在清理前，应该先看这个pattern在Redis的INFO stats里有没有对应的keyspace_hits数据，或者用客户端埋点观察一段时间的访问频次。高频访问的key，哪怕暂时没用，也别一刀切。
最后说一点个人体会
这套方案跑完之后，我最大的感触是：DeepSeek确实能帮我们省掉很多“查手册”的时间，它把Shell脚本的骨架、SCAN的用法、--pipe的注意事项都给你排好了，但你自己的判断力没法外包。比如哪些key能删、哪些不能删，脚本再聪明也不知道你业务里cart_和user_info_的区别。
我现在的习惯是：让DeepSeek生成第一版，然后人工review每一行命令，再在测试环境架一套一模一样的Redis演练一遍，最后才敢动生产。Redis数据删了就真的没了，备份、dry-run、灰度这三个动作，一个都不能省。
