提到 Redis大多数人入门时先学的就是那一小撮看起来最简单的命令SET、GET、DEL、EXPIRE。在文档里它们被归在 Generic Commands 这一组中文习惯叫Redis 通用命令。说实话我刚工作那会儿也觉得这十几个命令没什么深度真正用熟只需要半天。直到后来在线上因为一条 DEL 把主线程卡了两秒因为 KEYS 让一个几百万 key 的实例差点进入不可服务状态又因为 TTL 返回的 -1 和 -2 被我记反排障时白白绕了一个大弯我才意识到通用命令恰恰是整个 Redis 命令体系里最容易被低估的一类。这篇文章想聊聊我自己整理 Redis 通用命令的完整思路每个高频命令的语义边界、参数组合、阻塞风险以及在日常开发和线上运维中应该遵守的操作纪律。适合刚学完 Redis 五种数据结构、想深入理解命令底层行为的读者也适合已经写过一阵子 Redis、想系统查漏补缺的朋友。文中涉及的命令演示我用的是 Redis 7.x 的行为兼容 4.0 以上的绝大部分场景。1. 通用命令在 Redis 命令体系里的特殊位置1.1 两级抽象数据结构命令与通用命令Redis 的命令体系可以粗分成两层。底层是各数据结构的专属命令比如字符串的 INCR、哈希的 HSET、列表的 LPUSH、集合的 SADD、有序集合的 ZADD这些命令只对特定类型有意义。上层则是本文要聊的通用命令它们不关心 value 的内部类型直接作用在 key 这一抽象层检查 key 是否存在、删除 key、查看剩余过期时间、给 key 设置过期时间。这个分层非常关键。很多新手把精力都花在背数据结构命令上对通用命令的语义反而一知半解。但在实际项目里通用命令的使用频率远高于任何一组数据结构命令。判断缓存 key 是否命中、清理临时数据、排查线上问题、评估实例内存水位靠来靠去都是这十几个命令。我经常跟团队里的新人说一句话数据结构命令决定你能用 Redis 做什么通用命令决定你能不能把 Redis 用得稳。前者是功能边界后者是运维底线。1.2 为什么容易出问题的偏偏是它们通用命令作用在 key 抽象层这意味着一条命令的影响范围可能横跨所有数据类型。DEL 一个 string key 和 DEL 一个包含上百万字段的 hash key从命令格式上看毫无区别内部工作量却是天壤之别。KEYS 在一个几百万 key 的实例上做模糊匹配会让单线程的 Redis 完全停下来处理匹配逻辑期间所有读写请求全部排队。另一个容易被忽略的问题是通用命令的返回值经常携带暗号。TTL 的 -1 和 -2 含义不同EXISTS 一次传多个 key 返回的是存在数量SCAN 的游标从 0 开始、回到 0 才算真正遍历结束。这些细节如果不亲自验证只靠印象去猜排障时很容易被误导。2. SET/GET/DEL 的边界和隐藏参数读写命令的完整语义2.1 SET 的 NX、XX、EX 参数一个命令当三个用SET 的完整语法很多人只记得SET key value这一种形态。实际它还有几个高频参数值得认真掌握SET key value [NX | XX] [EX seconds | PX milliseconds] [GET]NX仅当 key 不存在时写入相当于新建语义。XX仅当 key 已存在时写入相当于更新语义。EX / PX同时设置过期时间单位分别是秒和毫秒。GET写入前返回旧值如果旧值不是字符串会报错。我最常用来做的是分布式锁的最小实现SET lock:order:1001 token NX EX 30。这一条命令同时完成判断不存在、写入、设置超时三个动作原子性天然成立。早期不少教程还在推荐先用 SETNX 再用 EXPIRE的两步操作这两步之间如果进程崩溃锁就会变成永不释放的僵尸锁。现在完全没有必要再这么写。XX 参数则适合做缓存覆写。比如只允许已存在的 key 被更新防止并发环境下先把旧值覆盖了。配合 GET 参数还能拿到旧值做对比省一次额外查询。2.2 GET 的类型限制不是所有值都能直接读GET 不是真正通用的读命令它只对 string 类型生效。如果你对一个 hash 或 list 类型的 key 执行 GETRedis 会返回WRONGTYPE Operation against a key holding the wrong kind of value这个报错在开发环境不常见但在线上很常见。原因通常是代码里某个 key 的前缀被复用了不同业务模块往同一个 key 里写了不同类型的值。我之前就遇到过一个缓存 key平时存的是 JSON 字符串某次发版后一段新代码用 HSET 往里塞了 hash结果所有读这个 key 的接口全部报 WRONGTYPE。遇到这种报错第一反应不是改代码而是先用TYPE key确认线上 key 的真实类型再决定是清理数据还是修正代码。2.3 DEL 的 O(N) 风险和 UNLINK 异步删除DEL 的复杂度需要掰开看。删除字符串类型的 key 是 O(1)但如果删的是一个包含几十万元素的 list、hash、set 或 zsetRedis 需要在主线程里逐个释放这些元素的内存整体复杂度是 O(M)M 是元素数量。在元素量大时这条 DEL 足以让 Redis 主线程阻塞几十毫秒甚至几秒。我实际碰到过一次某项目在夜间任务里清理一批临时 hash key其中一个 key 里有八十多万个字段。DEL 执行时监控图上 ops 直接掉到接近 0持续了大概一点几秒。好在是低峰期没有造成明显事故但那次之后我就把项目里所有删大 key 的操作统一改成了 UNLINK。UNLINK 是 Redis 4.0 引入的异步删除命令它把释放内存的动作交给后台线程处理主线程只负责把 key 从键空间里摘掉返回值依然是删除是否成功。对调用方来说UNLINK 和 DEL 的返回效果一致但阻塞风险大幅下降。如果你的 Redis 版本是 4.0 以上建议把所有可能删除大 key 的场景都默认用 UNLINK。也可以通过配置lazyfree-lazy-user-del yes让 DEL 直接走异步逻辑不过我更推荐显式使用 UNLINK代码意图更清楚。2.4 批量操作的 MSET/MGET 与 Pipeline 取舍循环 100 次调用 SET 意味着 100 次网络往返。在网络延迟 1ms 的数据中心内部环境下100 次就是 100ms如果客户端和 Redis 之间有公网延迟这个数字会更难看。批量操作的第一个选择是 MSET / MGETMSET user:1001:name 张明 user:1001:age 28 user:1001:city 上海 MGET user:1001:name user:1001:age user:1001:cityMSET 是一条命令写入多个 keyMGET 一条命令读出多个 key往返次数从 N 次降到 1 次吞吐提升立竿见影。但 MSET / MGET 只能覆盖 string 类型也不能处理像每个 key 独立设置过期时间这样的个性化需求。这时候可以用 Pipeline把一组 SET、EXPIRE、DEL 等命令打包在一次网络请求里发给 RedisRedis 依次执行后把结果一次性返回。Pipeline 的注意点有两个。第一它不具备事务性中间某条命令失败不影响其他命令执行不要把它当作原子批量操作。第二Pipeline 打包的命令数不是越多越好。我之前见过有人一个 Pipeline 塞了两万条命令客户端缓冲区被撑爆直接掉线。一般建议单批控制在几百到一两千条具体以压测为准。3. 过期生命周期EXPIRE、TTL、PERSIST 的返回值暗号3.1 设置过期的三种方式与选择给 key 设置过期时间常见写法有三种SET key value EX 3600SETEX key 3600 valueSET key value之后再调用EXPIRE key 3600前两种都是原子完成写入 设置过期我更推荐第一种因为它的参数形式统一后续如果要把过期时间改成毫秒级别只需把 EX 换成 PX其他逻辑不动。至于第三种分开写的方式存在一个时间窗口写完值之后、设置过期之前如果进程崩溃这个 key 就成了永不过期的脏数据。如果需要动态调整过期时间可以直接对已有 key 调用 EXPIRE。Redis 7.0 还支持给 EXPIRE 追加 NX、XX、GT、LT 参数用于只在特定条件下更新过期时间比如 LT 表示仅当新过期时间比当前更早时更新适合做滑动续期类逻辑但日常用得不多。3.2 TTL 的三种返回值正数、-1、-2TTL 是查看 key 剩余存活时间的命令返回值的语义有三个分支正数剩余存活秒数。-1key 存在但没有设置过期时间。-2key 不存在。我见过不少人在排障时把 -1 和 -2 搞混。-1 只代表没设过期key 本身还在-2 才是这个 key 根本没存在过。判断缓存是否命中应该用 EXISTS 或 GET而不应该依赖 TTL 的返回值因为一个永远不过期的 key 用 TTL 看是 -1非常容易误判为查不到数据。如果要移除 key 的过期时间让它永久存活用 PERSIST。这在某些临时 key 转长期 key的场景下有效但操作前要确认这个 key 是否真的不需要过期策略否则它会一直在内存里占位置。3.3 固定过期时间引发的缓存雪崩与随机偏移一个经典问题批量缓存预热时所有 key 都设置 3600 秒过期。它们在同一时刻写入也会在同一时刻过期。过期瞬间大量请求同时回源数据库数据库压力瞬间拉满这就是缓存雪崩的一种典型成因。解决办法不是不用缓存而是把过期时间做一个随机偏移SET user:1001:profile ... EX 3600 SET user:1002:profile ... EX 3720 SET user:1003:profile ... EX 3550实际操作中代码里可以给基础过期时间加一个 0 到 600 秒的随机数让过期时间分散在一个区间内。我在某电商促销活动里用过这个方案基础 TTL 定在 300 秒随机增加 0 到 300 秒缓存过期回源引起的数据库峰值明显比固定 TTL 时平缓很多。3.4 过期触发机制与超大 key 过期阻塞Redis 的 key 过期依赖两种机制惰性删除和主动删除。惰性删除是当某个 key 被访问时发现它已过期就顺手删除主动删除是后台定时采样一批已过期的 key 并清理。但有一个细节容易被忽略如果一个大 key 到了过期时间被主动删除释放这块大内存的操作同样会发生在主线程里跟 DEL 大 key 一样可能造成阻塞。Redis 4.0 引入的惰性释放机制也覆盖了这个场景通过lazyfree-lazy-expire yes可以让过期 key 的内存释放转移到后台线程。建议在内存型业务里开启这个配置代价很小收益很实在。4. 键管理命令的暗礁KEYS、SCAN、TYPE、RENAME 的实战教训4.1 KEYS 的全局阻塞与 SCAN 游标方案KEYS pattern 可能是通用命令里最危险的一个。它需要遍历整个键空间做正则匹配在几百万 key 的实例上执行时Redis 主线程会被一直占住直到匹配完成。这个时间可能是几秒甚至十几秒期间所有读写请求都排在后面。生产环境的标准做法是禁用 KEYS改用 SCAN。SCAN 是游标式遍历每次只返回一小批 key配合下一次调用传入的游标继续迭代不会一次性把所有 key 都扫描出来。这里要记住三个语义第一次调用游标从 0 开始每次返回新的游标当返回的游标是 0 时表示遍历完成。COUNT 参数只是提示不是精确保证实际每次返回的 key 数量可能不同。遍历过程中 key 可能被新增或删除SCAN 不保证结果完全一致也可能返回重复 key。4.2 SCAN 批量删除指定前缀键的标准循环我经常需要在线上清理一批带相同前缀的临时 key比如tmp:*。正确姿势是 SCAN 批量 UNLINK而不是先 KEYS 再 DEL。伪代码逻辑如下cursor 0 loop: cursor, keys SCAN cursor MATCH tmp:* COUNT 1000 if len(keys) 0: UNLINK keys... if cursor 0: break需要注意两点。第一返回的 key 可能有重复考虑到 UNLINK 对不存在的 key 只是返回 0重复执行没有副作用所以通常不需要专门去重。第二如果线上流量很高SCAN 对 CPU 仍有开销建议在低峰期执行并且控制 COUNT 不要太大。4.3 TYPE 与 EXISTS操作前的身份确认TYPE key 返回 key 对应的数据类型常见值是 string、list、set、zset、hash、stream、none。它是一个 O(1) 命令成本很低适合在异常排查时第一时间确认 key 的真实类型。EXISTS key [key...] 的返回值是数字表示指定的一批 key 中有多少个存在。如果只传一个 key返回值就只有 0 或 1。这一点在监控告警里很有用比如写脚本每分钟检查三个核心缓存 keyEXISTS 返回 2 就说明有一个丢了可以直接触发告警。4.4 RENAME 覆盖与 RENAMENX 的取舍RENAME key newkey 会把 key 改名成 newkey如果 newkey 已经存在原来的值会被直接覆盖没有任何提示。这个覆盖行为在特定场景下有风险比如两个模块共用同一个 key 的命名约定一段脚本把某个 key 重命名到另一个业务正在使用的名字上就等于把对方的数据瞬间清空了。如果希望只在目标 key 不存在时重命名用 RENAMENX。它在业务上有一种典型用法实现抢占式迁移把旧 key 改到新名字但同时保证不会覆盖别人正在写入的数据。虽然实际场景不多但知道这个区别可以避免写代码时凭直觉用错命令。5. 服务器运维INFO、CONFIG、FLUSH、SELECT 的操作纪律5.1 INFO 的黄金指标内存、连接、持久化INFO 命令返回整个实例的运行状态按段输出server、clients、memory、persistence、stats、replication、cpu、keyspace 等。排查问题的时候我最关注的指标有三个。第一个是内存段。used_memory表示当前分配的内存总量used_memory_rss是操作系统视角下的常驻内存两者差距大通常说明内存碎片化maxmemory则决定 Redis 何时开始走淘汰策略。当used_memory接近maxmemory时就要赶紧查大 key 和过期清理情况。第二个是客户端段。connected_clients是当前连接数blocked_clients是阻塞等待中的连接数。如果 blocked_clients 长期不为 0说明有命令在阻塞主线程比如 BLPOP 等待数据或者某条慢命令卡住了 Redis。第三个是 stats 段的evicted_keys。这个数字表示因内存达到上限而被淘汰的 key 数量。如果 evicted_keys 持续上涨意味着内存压力很大大量缓存被强制驱逐缓存命中率会直线下降。5.2 SELECT 多库与 db0 之争Redis 默认自带 16 个逻辑库可以用 SELECT 切换。很多初学者喜欢把不同业务的数据放在不同 db 里比如 db0 放缓存、db1 放 session。我不建议在生产环境这么做。原因有几个。第一SCAN、KEYS、FLUSHALL 这类命令的粒度和 db 并不总是好用比如排查问题时要在不同 db 之间反复切换非常别扭。第二db 只是逻辑隔离底层内存是共享的一个 db 的内存压力照样拖垮整个实例。第三使用多 db 后误操作的概率显著上升比如有人想在 db1 执行 FLUSHDB结果 SELECT 没切过去把 db0 的业务数据清了。我见过的绝大多数成熟团队都只用 db0业务隔离靠 key 前缀区分实例隔离靠部署多套 Redis。这样操作边界清晰也方便后续做集群扩展因为 Redis Cluster 本身就不支持跨 db。5.3 FLUSHDB/FLUSHALL 的同步阻塞与 ASYNC 参数FLUSHDB 清空当前 dbFLUSHALL 清空整个实例。这条命令可以在毫秒级清掉全部数据但它默认是同步的把这么多 key 和内存一次性释放主线程会卡住相当久实例越大卡得越久。Redis 4.0 开始FLUSHALL 和 FLUSHDB 都支持 ASYNC 参数FLUSHALL ASYNC加上 ASYNC 后数据清理交给后台线程主线程立刻返回。我自己的操作纪律是任何环境都不手工执行不带 ASYNC 的 FLUSHALL。如果一定要清库先确认当前环境再确认实例角色最后再加上 ASYNC。曾经某测试环境被人直接 FLUSHALL因为实例上有大量测试数据同步清理让 Redis 停顿了两三秒虽然测试环境无所谓但这个习惯一旦养成换到生产环境就是灾难。另外SLOWLOG GET 可以查慢命令历史如果怀疑有人执行过 FLUSHALL慢日志里通常会留下记录这也是事后排查的有力线索。5.4 CLIENT LIST 与连接排障CLIENT LIST 会输出当前所有客户端连接的信息包括客户端地址、连接名称、db 编号、最后执行的命令、输入缓冲区大小等。接口偶发超时、连接数异常飙高的场景第一件事就是执行它看看连接从哪里来、在做什么、缓冲区有没有被撑大。配合 CLIENT KILL 可以定向清理异常连接。比如某个客户端因为 bug 一直保持空闲连接不放连接数打满 maxclients可以按地址批量杀掉。线上排障时这个命令比重启实例温和得多至少不会丢数据。6. 把这些命令串起来一次典型的缓存故障排错6.1 场景一缓存突然大面积失效现象接口报错率上升数据库查询量翻倍缓存命中率骤降。排障路径先INFO stats看expired_keys和evicted_keys。如果expired_keys在短时间窗口内集中增长说明大量 key 在同一时间段过期回源请求集中打到了数据库。接着用 SCAN 抽查几个业务 key 的 TTL确认它们的过期时间是否高度集中在同一秒附近。这类问题的修复方向是把过期时间加随机偏移或者把缓存 Preload 逻辑改成渐进式预热不要同一时刻全部写入。6.2 场景二接口超时与连接堆积现象Redis 本身 CPU 不高但客户端大量超时INFO clients里connected_clients很高blocked_clients不为 0。排障路径先CLIENT LIST重点看有没有连接正在执行耗时命令再SLOWLOG GET拉最近的慢命令。如果有 KEYS、DEL 大 key、FLUSHALL 这类记录问题基本就定位到了。我当时遇到的情况是一条 DEL 大 key 导致主线程卡了 800ms所有在这段时间内发起的命令全部排队客户端等不到响应就批量超时。修复方案是把删除改成 UNLINK并给清理任务加上限流。6.3 场景三大 key 导致的周期性 CPU 抖动现象实例 CPU 每隔一段时间出现尖峰伴随阻塞命令。排障路径用redis-cli --bigkeys扫描实例中体积最大的 key或者用DEBUG OBJECT key查看某个 key 的serializedlength快速定位大 key。找到之后评估这个 key 是否还需要完整存在于 Redis如果只是临时聚合数据可以拆分成多个小 key或者用哈希分片的方式降低单个 key 的体积。这类问题的根因通常不是某个命令用错了而是数据结构设计没有考虑单 key 容量的上限。通用命令只是帮你把它暴露出来。7. 一些通用命令的使用习惯7.1 前缀规范与脚本化清理通用命令里最需要配合约定来使用的是 SCAN、DEL 这类批量操作。我建议所有 Redis key 都带业务前缀比如order:lock:*、user:profile:*、tmp:*。有了前缀规范清理临时数据、监控特定业务缓存、统计缓存规模都只需要一条 SCAN 就能圈定范围。没有前缀规范你连这个 key 是谁写的都查不清楚。批量清理逻辑最好写成脚本或工具函数固定使用 SCAN UNLINK 的循环模式不要每次手工敲 KEYS 再删。脚本里还可以加一个确认环境的开关比如必须传入环境参数才能执行避免在错误的实例上跑了清理任务。7.2 线上危险操作的自我保护涉及 FLUSHALL、大量 DEL、RENAME 这类可能造成数据丢失或阻塞的命令我个人的习惯是三个先先在预发环境完整演练一遍先确认实例角色和连接地址先在命令末尾加上 ASYNC 或使用 UNLINK 这类异步版本。另外尽量避免直接在命令行手工敲删除类命令。人都可能打错字把user:*打成一个更宽的前缀一次误操作要恢复可能需要从备份重新同步。把操作收敛到脚本、工具甚至内部管理平台里比靠个人记忆力靠谱得多。7.3 简化记忆把通用命令按功能分组最后分享一个记忆方法。我从不孤立地背通用命令而是按功能把它们分成四组读写删除组SET、GET、MSET、MGET、DEL、UNLINK生命周期组EXPIRE、TTL、PERSIST、SETEX键查询组EXISTS、TYPE、KEYS、SCAN、RENAME运维管理组PING、INFO、CONFIG、CLIENT、FLUSHDB、FLUSHALL、DBSIZE分组之后遇到问题能快速定位该用哪一组。新人在排查线上问题的时候往往不是不知道某个命令而是不知道此刻该调出哪一组的命令。把这个分组挂在脑子里排障思路会清晰很多。我这几年在 Redis 通用命令上踩过的坑几乎都集中在高估命令的简单性这件事上。一个看起来人畜无害的 DEL可能因为 key 的规模变成阻塞炸弹一个看起来功能完善的 KEYS可能因为键空间太大拖垮整个实例。如果你能把每个通用命令的返回值、复杂度、阻塞边界都像背自己名字一样熟悉线上 Redis 的稳定性和可维护性会提升一个档次。
提到 Redis大多数人入门时先学的就是那一小撮看起来最简单的命令SET、GET、DEL、EXPIRE。在文档里它们被归在 Generic Commands 这一组中文习惯叫Redis 通用命令。说实话我刚工作那会儿也觉得这十几个命令没什么深度真正用熟只需要半天。直到后来在线上因为一条 DEL 把主线程卡了两秒因为 KEYS 让一个几百万 key 的实例差点进入不可服务状态又因为 TTL 返回的 -1 和 -2 被我记反排障时白白绕了一个大弯我才意识到通用命令恰恰是整个 Redis 命令体系里最容易被低估的一类。这篇文章想聊聊我自己整理 Redis 通用命令的完整思路每个高频命令的语义边界、参数组合、阻塞风险以及在日常开发和线上运维中应该遵守的操作纪律。适合刚学完 Redis 五种数据结构、想深入理解命令底层行为的读者也适合已经写过一阵子 Redis、想系统查漏补缺的朋友。文中涉及的命令演示我用的是 Redis 7.x 的行为兼容 4.0 以上的绝大部分场景。1. 通用命令在 Redis 命令体系里的特殊位置1.1 两级抽象数据结构命令与通用命令Redis 的命令体系可以粗分成两层。底层是各数据结构的专属命令比如字符串的 INCR、哈希的 HSET、列表的 LPUSH、集合的 SADD、有序集合的 ZADD这些命令只对特定类型有意义。上层则是本文要聊的通用命令它们不关心 value 的内部类型直接作用在 key 这一抽象层检查 key 是否存在、删除 key、查看剩余过期时间、给 key 设置过期时间。这个分层非常关键。很多新手把精力都花在背数据结构命令上对通用命令的语义反而一知半解。但在实际项目里通用命令的使用频率远高于任何一组数据结构命令。判断缓存 key 是否命中、清理临时数据、排查线上问题、评估实例内存水位靠来靠去都是这十几个命令。我经常跟团队里的新人说一句话数据结构命令决定你能用 Redis 做什么通用命令决定你能不能把 Redis 用得稳。前者是功能边界后者是运维底线。1.2 为什么容易出问题的偏偏是它们通用命令作用在 key 抽象层这意味着一条命令的影响范围可能横跨所有数据类型。DEL 一个 string key 和 DEL 一个包含上百万字段的 hash key从命令格式上看毫无区别内部工作量却是天壤之别。KEYS 在一个几百万 key 的实例上做模糊匹配会让单线程的 Redis 完全停下来处理匹配逻辑期间所有读写请求全部排队。另一个容易被忽略的问题是通用命令的返回值经常携带暗号。TTL 的 -1 和 -2 含义不同EXISTS 一次传多个 key 返回的是存在数量SCAN 的游标从 0 开始、回到 0 才算真正遍历结束。这些细节如果不亲自验证只靠印象去猜排障时很容易被误导。2. SET/GET/DEL 的边界和隐藏参数读写命令的完整语义2.1 SET 的 NX、XX、EX 参数一个命令当三个用SET 的完整语法很多人只记得SET key value这一种形态。实际它还有几个高频参数值得认真掌握SET key value [NX | XX] [EX seconds | PX milliseconds] [GET]NX仅当 key 不存在时写入相当于新建语义。XX仅当 key 已存在时写入相当于更新语义。EX / PX同时设置过期时间单位分别是秒和毫秒。GET写入前返回旧值如果旧值不是字符串会报错。我最常用来做的是分布式锁的最小实现SET lock:order:1001 token NX EX 30。这一条命令同时完成判断不存在、写入、设置超时三个动作原子性天然成立。早期不少教程还在推荐先用 SETNX 再用 EXPIRE的两步操作这两步之间如果进程崩溃锁就会变成永不释放的僵尸锁。现在完全没有必要再这么写。XX 参数则适合做缓存覆写。比如只允许已存在的 key 被更新防止并发环境下先把旧值覆盖了。配合 GET 参数还能拿到旧值做对比省一次额外查询。2.2 GET 的类型限制不是所有值都能直接读GET 不是真正通用的读命令它只对 string 类型生效。如果你对一个 hash 或 list 类型的 key 执行 GETRedis 会返回WRONGTYPE Operation against a key holding the wrong kind of value这个报错在开发环境不常见但在线上很常见。原因通常是代码里某个 key 的前缀被复用了不同业务模块往同一个 key 里写了不同类型的值。我之前就遇到过一个缓存 key平时存的是 JSON 字符串某次发版后一段新代码用 HSET 往里塞了 hash结果所有读这个 key 的接口全部报 WRONGTYPE。遇到这种报错第一反应不是改代码而是先用TYPE key确认线上 key 的真实类型再决定是清理数据还是修正代码。2.3 DEL 的 O(N) 风险和 UNLINK 异步删除DEL 的复杂度需要掰开看。删除字符串类型的 key 是 O(1)但如果删的是一个包含几十万元素的 list、hash、set 或 zsetRedis 需要在主线程里逐个释放这些元素的内存整体复杂度是 O(M)M 是元素数量。在元素量大时这条 DEL 足以让 Redis 主线程阻塞几十毫秒甚至几秒。我实际碰到过一次某项目在夜间任务里清理一批临时 hash key其中一个 key 里有八十多万个字段。DEL 执行时监控图上 ops 直接掉到接近 0持续了大概一点几秒。好在是低峰期没有造成明显事故但那次之后我就把项目里所有删大 key 的操作统一改成了 UNLINK。UNLINK 是 Redis 4.0 引入的异步删除命令它把释放内存的动作交给后台线程处理主线程只负责把 key 从键空间里摘掉返回值依然是删除是否成功。对调用方来说UNLINK 和 DEL 的返回效果一致但阻塞风险大幅下降。如果你的 Redis 版本是 4.0 以上建议把所有可能删除大 key 的场景都默认用 UNLINK。也可以通过配置lazyfree-lazy-user-del yes让 DEL 直接走异步逻辑不过我更推荐显式使用 UNLINK代码意图更清楚。2.4 批量操作的 MSET/MGET 与 Pipeline 取舍循环 100 次调用 SET 意味着 100 次网络往返。在网络延迟 1ms 的数据中心内部环境下100 次就是 100ms如果客户端和 Redis 之间有公网延迟这个数字会更难看。批量操作的第一个选择是 MSET / MGETMSET user:1001:name 张明 user:1001:age 28 user:1001:city 上海 MGET user:1001:name user:1001:age user:1001:cityMSET 是一条命令写入多个 keyMGET 一条命令读出多个 key往返次数从 N 次降到 1 次吞吐提升立竿见影。但 MSET / MGET 只能覆盖 string 类型也不能处理像每个 key 独立设置过期时间这样的个性化需求。这时候可以用 Pipeline把一组 SET、EXPIRE、DEL 等命令打包在一次网络请求里发给 RedisRedis 依次执行后把结果一次性返回。Pipeline 的注意点有两个。第一它不具备事务性中间某条命令失败不影响其他命令执行不要把它当作原子批量操作。第二Pipeline 打包的命令数不是越多越好。我之前见过有人一个 Pipeline 塞了两万条命令客户端缓冲区被撑爆直接掉线。一般建议单批控制在几百到一两千条具体以压测为准。3. 过期生命周期EXPIRE、TTL、PERSIST 的返回值暗号3.1 设置过期的三种方式与选择给 key 设置过期时间常见写法有三种SET key value EX 3600SETEX key 3600 valueSET key value之后再调用EXPIRE key 3600前两种都是原子完成写入 设置过期我更推荐第一种因为它的参数形式统一后续如果要把过期时间改成毫秒级别只需把 EX 换成 PX其他逻辑不动。至于第三种分开写的方式存在一个时间窗口写完值之后、设置过期之前如果进程崩溃这个 key 就成了永不过期的脏数据。如果需要动态调整过期时间可以直接对已有 key 调用 EXPIRE。Redis 7.0 还支持给 EXPIRE 追加 NX、XX、GT、LT 参数用于只在特定条件下更新过期时间比如 LT 表示仅当新过期时间比当前更早时更新适合做滑动续期类逻辑但日常用得不多。3.2 TTL 的三种返回值正数、-1、-2TTL 是查看 key 剩余存活时间的命令返回值的语义有三个分支正数剩余存活秒数。-1key 存在但没有设置过期时间。-2key 不存在。我见过不少人在排障时把 -1 和 -2 搞混。-1 只代表没设过期key 本身还在-2 才是这个 key 根本没存在过。判断缓存是否命中应该用 EXISTS 或 GET而不应该依赖 TTL 的返回值因为一个永远不过期的 key 用 TTL 看是 -1非常容易误判为查不到数据。如果要移除 key 的过期时间让它永久存活用 PERSIST。这在某些临时 key 转长期 key的场景下有效但操作前要确认这个 key 是否真的不需要过期策略否则它会一直在内存里占位置。3.3 固定过期时间引发的缓存雪崩与随机偏移一个经典问题批量缓存预热时所有 key 都设置 3600 秒过期。它们在同一时刻写入也会在同一时刻过期。过期瞬间大量请求同时回源数据库数据库压力瞬间拉满这就是缓存雪崩的一种典型成因。解决办法不是不用缓存而是把过期时间做一个随机偏移SET user:1001:profile ... EX 3600 SET user:1002:profile ... EX 3720 SET user:1003:profile ... EX 3550实际操作中代码里可以给基础过期时间加一个 0 到 600 秒的随机数让过期时间分散在一个区间内。我在某电商促销活动里用过这个方案基础 TTL 定在 300 秒随机增加 0 到 300 秒缓存过期回源引起的数据库峰值明显比固定 TTL 时平缓很多。3.4 过期触发机制与超大 key 过期阻塞Redis 的 key 过期依赖两种机制惰性删除和主动删除。惰性删除是当某个 key 被访问时发现它已过期就顺手删除主动删除是后台定时采样一批已过期的 key 并清理。但有一个细节容易被忽略如果一个大 key 到了过期时间被主动删除释放这块大内存的操作同样会发生在主线程里跟 DEL 大 key 一样可能造成阻塞。Redis 4.0 引入的惰性释放机制也覆盖了这个场景通过lazyfree-lazy-expire yes可以让过期 key 的内存释放转移到后台线程。建议在内存型业务里开启这个配置代价很小收益很实在。4. 键管理命令的暗礁KEYS、SCAN、TYPE、RENAME 的实战教训4.1 KEYS 的全局阻塞与 SCAN 游标方案KEYS pattern 可能是通用命令里最危险的一个。它需要遍历整个键空间做正则匹配在几百万 key 的实例上执行时Redis 主线程会被一直占住直到匹配完成。这个时间可能是几秒甚至十几秒期间所有读写请求都排在后面。生产环境的标准做法是禁用 KEYS改用 SCAN。SCAN 是游标式遍历每次只返回一小批 key配合下一次调用传入的游标继续迭代不会一次性把所有 key 都扫描出来。这里要记住三个语义第一次调用游标从 0 开始每次返回新的游标当返回的游标是 0 时表示遍历完成。COUNT 参数只是提示不是精确保证实际每次返回的 key 数量可能不同。遍历过程中 key 可能被新增或删除SCAN 不保证结果完全一致也可能返回重复 key。4.2 SCAN 批量删除指定前缀键的标准循环我经常需要在线上清理一批带相同前缀的临时 key比如tmp:*。正确姿势是 SCAN 批量 UNLINK而不是先 KEYS 再 DEL。伪代码逻辑如下cursor 0 loop: cursor, keys SCAN cursor MATCH tmp:* COUNT 1000 if len(keys) 0: UNLINK keys... if cursor 0: break需要注意两点。第一返回的 key 可能有重复考虑到 UNLINK 对不存在的 key 只是返回 0重复执行没有副作用所以通常不需要专门去重。第二如果线上流量很高SCAN 对 CPU 仍有开销建议在低峰期执行并且控制 COUNT 不要太大。4.3 TYPE 与 EXISTS操作前的身份确认TYPE key 返回 key 对应的数据类型常见值是 string、list、set、zset、hash、stream、none。它是一个 O(1) 命令成本很低适合在异常排查时第一时间确认 key 的真实类型。EXISTS key [key...] 的返回值是数字表示指定的一批 key 中有多少个存在。如果只传一个 key返回值就只有 0 或 1。这一点在监控告警里很有用比如写脚本每分钟检查三个核心缓存 keyEXISTS 返回 2 就说明有一个丢了可以直接触发告警。4.4 RENAME 覆盖与 RENAMENX 的取舍RENAME key newkey 会把 key 改名成 newkey如果 newkey 已经存在原来的值会被直接覆盖没有任何提示。这个覆盖行为在特定场景下有风险比如两个模块共用同一个 key 的命名约定一段脚本把某个 key 重命名到另一个业务正在使用的名字上就等于把对方的数据瞬间清空了。如果希望只在目标 key 不存在时重命名用 RENAMENX。它在业务上有一种典型用法实现抢占式迁移把旧 key 改到新名字但同时保证不会覆盖别人正在写入的数据。虽然实际场景不多但知道这个区别可以避免写代码时凭直觉用错命令。5. 服务器运维INFO、CONFIG、FLUSH、SELECT 的操作纪律5.1 INFO 的黄金指标内存、连接、持久化INFO 命令返回整个实例的运行状态按段输出server、clients、memory、persistence、stats、replication、cpu、keyspace 等。排查问题的时候我最关注的指标有三个。第一个是内存段。used_memory表示当前分配的内存总量used_memory_rss是操作系统视角下的常驻内存两者差距大通常说明内存碎片化maxmemory则决定 Redis 何时开始走淘汰策略。当used_memory接近maxmemory时就要赶紧查大 key 和过期清理情况。第二个是客户端段。connected_clients是当前连接数blocked_clients是阻塞等待中的连接数。如果 blocked_clients 长期不为 0说明有命令在阻塞主线程比如 BLPOP 等待数据或者某条慢命令卡住了 Redis。第三个是 stats 段的evicted_keys。这个数字表示因内存达到上限而被淘汰的 key 数量。如果 evicted_keys 持续上涨意味着内存压力很大大量缓存被强制驱逐缓存命中率会直线下降。5.2 SELECT 多库与 db0 之争Redis 默认自带 16 个逻辑库可以用 SELECT 切换。很多初学者喜欢把不同业务的数据放在不同 db 里比如 db0 放缓存、db1 放 session。我不建议在生产环境这么做。原因有几个。第一SCAN、KEYS、FLUSHALL 这类命令的粒度和 db 并不总是好用比如排查问题时要在不同 db 之间反复切换非常别扭。第二db 只是逻辑隔离底层内存是共享的一个 db 的内存压力照样拖垮整个实例。第三使用多 db 后误操作的概率显著上升比如有人想在 db1 执行 FLUSHDB结果 SELECT 没切过去把 db0 的业务数据清了。我见过的绝大多数成熟团队都只用 db0业务隔离靠 key 前缀区分实例隔离靠部署多套 Redis。这样操作边界清晰也方便后续做集群扩展因为 Redis Cluster 本身就不支持跨 db。5.3 FLUSHDB/FLUSHALL 的同步阻塞与 ASYNC 参数FLUSHDB 清空当前 dbFLUSHALL 清空整个实例。这条命令可以在毫秒级清掉全部数据但它默认是同步的把这么多 key 和内存一次性释放主线程会卡住相当久实例越大卡得越久。Redis 4.0 开始FLUSHALL 和 FLUSHDB 都支持 ASYNC 参数FLUSHALL ASYNC加上 ASYNC 后数据清理交给后台线程主线程立刻返回。我自己的操作纪律是任何环境都不手工执行不带 ASYNC 的 FLUSHALL。如果一定要清库先确认当前环境再确认实例角色最后再加上 ASYNC。曾经某测试环境被人直接 FLUSHALL因为实例上有大量测试数据同步清理让 Redis 停顿了两三秒虽然测试环境无所谓但这个习惯一旦养成换到生产环境就是灾难。另外SLOWLOG GET 可以查慢命令历史如果怀疑有人执行过 FLUSHALL慢日志里通常会留下记录这也是事后排查的有力线索。5.4 CLIENT LIST 与连接排障CLIENT LIST 会输出当前所有客户端连接的信息包括客户端地址、连接名称、db 编号、最后执行的命令、输入缓冲区大小等。接口偶发超时、连接数异常飙高的场景第一件事就是执行它看看连接从哪里来、在做什么、缓冲区有没有被撑大。配合 CLIENT KILL 可以定向清理异常连接。比如某个客户端因为 bug 一直保持空闲连接不放连接数打满 maxclients可以按地址批量杀掉。线上排障时这个命令比重启实例温和得多至少不会丢数据。6. 把这些命令串起来一次典型的缓存故障排错6.1 场景一缓存突然大面积失效现象接口报错率上升数据库查询量翻倍缓存命中率骤降。排障路径先INFO stats看expired_keys和evicted_keys。如果expired_keys在短时间窗口内集中增长说明大量 key 在同一时间段过期回源请求集中打到了数据库。接着用 SCAN 抽查几个业务 key 的 TTL确认它们的过期时间是否高度集中在同一秒附近。这类问题的修复方向是把过期时间加随机偏移或者把缓存 Preload 逻辑改成渐进式预热不要同一时刻全部写入。6.2 场景二接口超时与连接堆积现象Redis 本身 CPU 不高但客户端大量超时INFO clients里connected_clients很高blocked_clients不为 0。排障路径先CLIENT LIST重点看有没有连接正在执行耗时命令再SLOWLOG GET拉最近的慢命令。如果有 KEYS、DEL 大 key、FLUSHALL 这类记录问题基本就定位到了。我当时遇到的情况是一条 DEL 大 key 导致主线程卡了 800ms所有在这段时间内发起的命令全部排队客户端等不到响应就批量超时。修复方案是把删除改成 UNLINK并给清理任务加上限流。6.3 场景三大 key 导致的周期性 CPU 抖动现象实例 CPU 每隔一段时间出现尖峰伴随阻塞命令。排障路径用redis-cli --bigkeys扫描实例中体积最大的 key或者用DEBUG OBJECT key查看某个 key 的serializedlength快速定位大 key。找到之后评估这个 key 是否还需要完整存在于 Redis如果只是临时聚合数据可以拆分成多个小 key或者用哈希分片的方式降低单个 key 的体积。这类问题的根因通常不是某个命令用错了而是数据结构设计没有考虑单 key 容量的上限。通用命令只是帮你把它暴露出来。7. 一些通用命令的使用习惯7.1 前缀规范与脚本化清理通用命令里最需要配合约定来使用的是 SCAN、DEL 这类批量操作。我建议所有 Redis key 都带业务前缀比如order:lock:*、user:profile:*、tmp:*。有了前缀规范清理临时数据、监控特定业务缓存、统计缓存规模都只需要一条 SCAN 就能圈定范围。没有前缀规范你连这个 key 是谁写的都查不清楚。批量清理逻辑最好写成脚本或工具函数固定使用 SCAN UNLINK 的循环模式不要每次手工敲 KEYS 再删。脚本里还可以加一个确认环境的开关比如必须传入环境参数才能执行避免在错误的实例上跑了清理任务。7.2 线上危险操作的自我保护涉及 FLUSHALL、大量 DEL、RENAME 这类可能造成数据丢失或阻塞的命令我个人的习惯是三个先先在预发环境完整演练一遍先确认实例角色和连接地址先在命令末尾加上 ASYNC 或使用 UNLINK 这类异步版本。另外尽量避免直接在命令行手工敲删除类命令。人都可能打错字把user:*打成一个更宽的前缀一次误操作要恢复可能需要从备份重新同步。把操作收敛到脚本、工具甚至内部管理平台里比靠个人记忆力靠谱得多。7.3 简化记忆把通用命令按功能分组最后分享一个记忆方法。我从不孤立地背通用命令而是按功能把它们分成四组读写删除组SET、GET、MSET、MGET、DEL、UNLINK生命周期组EXPIRE、TTL、PERSIST、SETEX键查询组EXISTS、TYPE、KEYS、SCAN、RENAME运维管理组PING、INFO、CONFIG、CLIENT、FLUSHDB、FLUSHALL、DBSIZE分组之后遇到问题能快速定位该用哪一组。新人在排查线上问题的时候往往不是不知道某个命令而是不知道此刻该调出哪一组的命令。把这个分组挂在脑子里排障思路会清晰很多。我这几年在 Redis 通用命令上踩过的坑几乎都集中在高估命令的简单性这件事上。一个看起来人畜无害的 DEL可能因为 key 的规模变成阻塞炸弹一个看起来功能完善的 KEYS可能因为键空间太大拖垮整个实例。如果你能把每个通用命令的返回值、复杂度、阻塞边界都像背自己名字一样熟悉线上 Redis 的稳定性和可维护性会提升一个档次。
语法分析器实现指南：从FIRST集与FOLLOW集到预测分析表)
