1. 线上 Redis 突然变慢先别急着扩容如果你在用 TaoToken 这类统一 Key/API 通道把 AI 工具、编码助手、Agent 服务接到一起大概率会顺手把会话缓存、任务队列、限流计数、向量检索的中间结果都塞进 Redis。用着用着就会发现接口偶尔卡一下P99 延迟从 8ms 跳到 200ms慢查询日志里冒出一堆HGETALL、SMEMBERS、LRANGE。这时候很多人第一反应是「内存不够了加机器」但真正的原因往往不是总量而是某几个 key 大得离谱。大 key 的危害不在于它占了多少 GB而在于操作它的那一下会阻塞单线程的 Redis。一个 50 万 field 的 hash你执行一次HGETALLRedis 就得把这 50 万个 field 全部序列化返回这段时间整个实例的其他请求全部排队。我见过最典型的场景TaoToken 的调用日志按天写进一个 hash某天某个 key 因为重试逻辑写爆了直接拖垮了整个缓存层。所以这篇不讲怎么加内存讲怎么在不阻塞线上服务的前提下把那个「内存热点」揪出来。核心工具就三个redis-cli --bigkeys、SCAN游标扫描、MEMORY USAGE再补一个离线分析工具redis-rdb-tools做兜底。整套流程你可以直接复制到自己的环境里跑。2. 前置准备连上实例确认版本与权限在动手排查之前先把连接信息确认清楚。TaoToken 本身是统一 Key/API 通道不直接托管你的 Redis所以你需要拿到自己 Redis 实例的 host、port、密码。如果你是通过 TaoToken 的 Coding Plan 或模型对话服务间接用到缓存建议先到控制台确认后端 Redis 的连接参数避免扫错实例。# 基础连接测试确认网络与认证没问题 redis-cli -h 127.0.0.1 -p 16379 -a your_password ping # 返回 PONG 说明通了接着确认版本因为MEMORY USAGE需要 Redis 4.0--bigkeys的统计口径在不同版本也有差异redis-cli -h 127.0.0.1 -p 16379 -a your_password info server | grep redis_version权限方面如果你用的是云 Redis 或带 ACL 的实例当前账号至少要有SCAN、MEMORY、TYPE、OBJECT这几类命令的执行权限。生产环境建议单独开一个只读排查账号别拿业务主账号乱扫。注意--bigkeys会遍历整个 keyspace虽然它内部用的是 SCAN 不阻塞但高频调用TYPE和STRLEN/LLEN仍会带来额外 CPU 开销。务必在低峰期执行或者用-i参数控制节奏。3. 可复制配置三套命令组合定位大 key3.1 第一套redis-cli --bigkeys 快速摸底这是最快能出结果的方式一条命令扫全库按类型返回每种类型里最大的那个 keyredis-cli -h 127.0.0.1 -p 16379 -a your_password --bigkeys -i 0.1-i 0.1表示每扫描 100 次 sleep 0.1 秒降低对线上 CPU 的冲击。执行后你会看到类似输出[00.00%] Biggest hash found so far hash_large_key2 with 50000 fields [00.00%] Biggest string found so far string_large_key2 with 10485762 bytes [00.00%] Biggest set found so far set_large_key2 with 1 members [00.00%] Biggest list found so far list_large_key1 with 50000 items -------- summary ------- Sampled 9 keys in the keyspace! Total key length in bytes is 135 (avg len 15.00) Biggest list found list_large_key1 has 50000 items Biggest hash found hash_large_key2 has 50000 fields Biggest string found string_large_key2 has 10485762 bytes Biggest set found set_large_key2 has 1 members这里有几个坑必须提前说清楚。第一它每种类型只返回最大的那一个排第二第三的 bigkey 你看不到。第二对集合类型它统计的是元素个数不是实际内存。上面那个set_large_key2只有 1 个 member但那个 member 本身可能是个 10MB 的大字符串--bigkeys完全看不出来。第三它不区分业务前缀扫出来的 key 你得自己判断是不是该优化。所以--bigkeys只适合做第一轮粗筛真正定位还得靠下面这套组合。3.2 第二套SCAN 游标 MEMORY USAGE 精确测量--bigkeys底层其实也是 SCAN只是帮你封装好了。我们手动来一遍好处是可以按前缀过滤、可以拿到真实内存占用。先按业务前缀扫描 key比如你怀疑 TaoToken 的会话缓存前缀是session:*# 游标从 0 开始MATCH 过滤前缀COUNT 是每次返回的提示数量不是精确值 redis-cli -h 127.0.0.1 -p 16379 -a your_password scan 0 MATCH session:* COUNT 100返回结果第一行是下一次的游标第二行是这批 key 列表1) 1024 2) 1) session:user_1001 2) session:user_1002 3) session:user_1003拿到游标1024后继续扫直到游标回到0表示遍历完成。这一步的关键是不要用KEYS *那个命令会一次性阻塞整个实例生产环境绝对禁用。扫出候选 key 之后用MEMORY USAGE测真实内存redis-cli -h 127.0.0.1 -p 16379 -a your_password memory usage session:user_1001 # 返回 (integer) 10485831单位是字节如果你想批量测可以写个 shell 循环把 SCAN 结果喂进去#!/bin/bash HOST127.0.0.1 PORT16379 PASSyour_password CURSOR0 while true; do RESULT$(redis-cli -h $HOST -p $PORT -a $PASS scan $CURSOR MATCH session:* COUNT 100) CURSOR$(echo $RESULT | head -1 | tr -d ) KEYS$(echo $RESULT | tail -n 2) for k in $KEYS; do SIZE$(redis-cli -h $HOST -p $PORT -a $PASS memory usage $k) if [ $SIZE -gt 102400 ]; then echo $k $SIZE fi done [ $CURSOR 0 ] break done这段脚本会把超过 100KB 的 key 全部列出来配合sort -k2 -nr就能拿到内存占用排行榜。实测下来一个 50 万 field 的 hash 用MEMORY USAGE测出来大约 3.1MB而同样 field 数的 list 只有 744KB差距非常明显——这就是为什么不能只看元素个数。3.3 第三套redis-rdb-tools 离线分析兜底线上不方便跑脚本或者你想拿到全量 key 的精确内存分布就用 RDB 文件离线分析。先装工具pip3 install rdbtools python-lzfWindows 下如果报权限错误error: [Errno 13] Permission denied: C:\Python310\Scripts\rdb-script.py用管理员身份打开 cmd 再执行即可。装完后Scripts目录下会多出rdb.exe、redis-memory-for-key.exe等文件。然后对 RDB 文件做内存分析只输出大于 100KB 的 keyrdb --command memory --bytes 102400 /var/lib/redis/dump.rdb输出是 CSV 格式字段包括 database、type、key、size_in_bytes、encoding、num_elements 等database,type,key,size_in_bytes,encoding,num_elements,len_largest_element,expiry 0,hash,hash_large_key2,3186588,hashtable,50000,11, 0,string,string_large_key1,12582976,string,10485762,10485762, 0,list,list_large_key1,744355,quicklist,50000,13,想存到本地慢慢看就加-frdb --command memory --bytes 102400 /var/lib/redis/dump.rdb -f d:\kevin.csv这个方式完全不碰线上实例最安全缺点是数据有延迟得等最近一次 RDB 落盘。4. 验证请求确认大 key 分布与内存占用跑完上面三套你需要一个明确的验证动作确认自己找到的确实是内存热点。建议按这个顺序做第一步用TYPE确认 key 类型别对着一个 string 用HLENredis-cli -h 127.0.0.1 -p 16379 -a your_password type hash_large_key2 # 返回 hash第二步按类型看元素数量和MEMORY USAGE交叉验证redis-cli -h 127.0.0.1 -p 16379 -a your_password hlen hash_large_key2 # 返回 50000 redis-cli -h 127.0.0.1 -p 16379 -a your_password memory usage hash_large_key2 # 返回 3186588第三步看这个 key 的编码方式判断是否还能优化redis-cli -h 127.0.0.1 -p 16379 -a your_password object encoding hash_large_key2 # 返回 hashtable说明已经超过 ziplist 阈值无法再压缩如果返回listpack或ziplist说明元素还小内存占用可控返回hashtable、quicklist、skiplist就要警惕了。把这几步的结果整理成一张表你就能清楚看到哪些 key 是真正的内存热点key类型元素数内存占用编码hash_large_key2hash500003.18MBhashtablestring_large_key1string-12.58MBstringlist_large_key1list50000744KBquicklist从这张表能直接读出结论string 类大 key 内存最吓人hash 次之list 反而相对轻。优化优先级一目了然。5. 本篇常见错排查报错一(error) NOAUTH Authentication required连接时没带密码。加上-a your_password或者进交互模式后执行auth your_password。如果密码里有特殊字符用单引号包起来。报错二--bigkeys跑完发现漏了 key这是正常现象。--bigkeys每种类型只保留最大的一个而且对集合类型只数元素个数。如果你怀疑有多个大 key必须用第 3.2 节的 SCAN MEMORY USAGE 组合重新扫一遍。报错三MEMORY USAGE返回 nilkey 不存在或者你的 Redis 版本低于 4.0。先用exists key_name确认 key 在不在再info server看版本。低于 4.0 的实例只能用STRLEN、LLEN、HLEN这类命令估算精度差很多。报错四SCAN 扫到一半游标不归零SCAN 的游标是 64 位无符号整数返回0才代表遍历结束。如果你中途改了 MATCH 条件游标状态就乱了必须重新从0开始。另外 SCAN 只保证遍历期间一直存在的 key 会被返回遍历过程中新增或删除的 key 行为不确定这是设计如此不是 bug。报错五rdb 工具报ModuleNotFoundError: No module named lzf少了 python-lzf 依赖执行pip3 install python-lzf。Windows 上如果编译失败装个预编译 wheel 或者直接用 WSL 跑。报错六线上执行 SCAN 导致 CPU 飙高COUNT 设太大了。默认 10 就够别一上来设 1000。配合-i参数在--bigkeys里控制节奏手动 SCAN 时可以在脚本里加sleep 0.01。6. 排查完之后把通道和缓存一起管起来大 key 排查不是一次性任务而是持续运维的一部分。我的建议是把上面那套 SCAN MEMORY USAGE 脚本做成定时任务每天低峰期跑一次超过阈值的 key 自动告警。同时如果你在用 TaoToken 统一管理 AI 工具的 Key 和调用通道缓存层的健康度也应该纳入同一个监控面板——毕竟通道再稳后端 Redis 被一个大 key 卡住整个链路照样超时。具体到操作上你可以到 TaoToken 控制台生成独立的 API Key把排查脚本的调用日志和告警通知接到同一个通道里这样缓存异常和通道异常能一起看到。接入文档里有完整的鉴权和请求示例照着配就行。如果你还在选长期编码方案Coding Plan 那套额度模型对这类周期性运维任务更友好不用每次单独算调用量。最后留一个我踩过的坑别在业务高峰期用KEYS *图省事那个命令的阻塞时间和大 key 数量成正比我见过一次直接让实例卡了 8 秒。SCAN 慢一点但线上服务不会抖。