用 Redis 的人大概能分成两类一类把所有东西都塞成字符串另一类是真把 Redis 的数据类型当数据结构在用。前者往往在项目跑到第三个月时开始收到内存告警和慢查询日志然后回头补课我当年就是。这一篇接着上一篇的安装与配置往下走专门聊 Redis 的数据类型和常见命令。但我不打算给你搬一份help命令清单那东西随时能查我想讲的是每种类型在内存里到底长什么样、底层用什么编码、哪几条命令拼起来能解决实际问题、以及哪些命令看着人畜无害一执行就能把线上实例按住好几秒。数据类型决定的不只是能存什么还决定了内存占用、命令时间复杂度和并发行为。同一个业务需求用 String 存 JSON 和用 Hash 存 field内存能差出三倍用KEYS和用SCAN遍历一个是阻塞单线程一个是分批游标。这些差别在本地测试环境里几乎看不出来因为数据量小、没有并发等上了生产才暴露。所以这篇的写法是每种类型先把编码和结构讲透再落到具体命令最后给出我在实际项目里踩过或见过的问题。适合谁看已经能跑起一个 Redis 实例、会敲SET/GET但对自己写的命令在生产环境什么表现没底的人或者正在做技术选型纠结排行榜该用 List 还是 ZSet、签到该用 Set 还是 Bitmap 的人。如果你连 Redis 都还没装建议先回到上一篇把环境搞定这篇默认你手上有一个可用的实例。1. 先建立类型的结构认知再谈命令怎么记很多人学 Redis 命令的方式是背表格String 有哪些命令、Hash 有哪些命令。背完一圈下来遇到具体问题时还是不知道选哪个。根本原因是命令是结构的操作接口不理解结构命令就只是一堆孤立的动词。我先花点篇幅把类型的底层讲清楚后面所有命令的选择判断都从这里推出来。1.1 五种基础类型共享同一套字典底盘Redis 的键空间本身就是一个大字典key是字符串value是一个redisObject。这个redisObject里有一个type字段标明它是 String、Hash、List、Set 还是 ZSet还有一个encoding字段标明它底下实际用什么结构实现。这是理解一切的关键type 是你看到的类型encoding 是 Redis 实际用的结构两者不是一一对应的。比如你SET一个123它的 type 是 stringencoding 是 intSET一个 40 字节的字符串encoding 是 embstrSET一个 100 字节的字符串encoding 变成 raw。你什么都没改命令也一样但底层结构换了内存布局和操作方式都变了。Hash 同理小的时候是紧凑的 listpack超过阈值就变成 hashtable。这种编码随数据规模自动切换的设计是 Redis 用一份内存同时兼顾小对象紧凑和大对象高效的核心手段。另外还有几个不算基础五类型但很实用的结构Bitmap 本质是 String 的位操作HyperLogLog 是 String 的特殊编码GEO 底层是 ZSetStream 是 5.0 引入的独立类型。它们不是新数据结构而是既有结构上的封装理解这一点能省掉很多困惑——比如为什么 HyperLogLog 的类型是 string为什么 GEO 的 key 用ZRANGE也能查出来。1.2 用 OBJECT ENCODING 反推内存编码判断一个 key 当前用什么编码最直接的办法是OBJECT ENCODING。这个命令在排查内存问题和性能问题时非常有用我几乎每次接手一个不熟悉的实例都会先扫一遍。127.0.0.1:6379 SET counter 100 OK 127.0.0.1:6379 OBJECT ENCODING counter int 127.0.0.1:6379 SET short hello OK 127.0.0.1:6379 OBJECT ENCODING short embstr 127.0.0.1:6379 SET long 这是一个超过四十四字节的字符串用来触发编码切换看看会不会变成raw编码继续补足长度 OK 127.0.0.1:6379 OBJECT ENCODING long raw 127.0.0.1:6379 HSET user:1 name A同学 age 24 (integer) 2 127.0.0.1:6379 OBJECT ENCODING user:1 listpack编码阈值在配置文件里有对应参数改这些参数会直接影响内存和性能是调优时最该先看的一批配置类型编码触发的阈值参数默认值说明Stringint长度 ≤ 20 且可解析为整数直接存 longStringembstr长度 ≤ 44 字节一次分配只读Stringraw长度 44 字节可追加需二次分配Hashlistpackhash-max-listpack-entries 128、hash-max-listpack-value 64任一超限即转 hashtableListquicklistlist-max-listpack-size 128每个节点是 listpackSetintset / listpack / hashtableset-max-intset-entries 512、set-max-listpack-entries 128全整数走 intsetZSetlistpack / skiplistzset-max-listpack-entries 128、zset-max-listpack-value 64超限转跳表注意OBJECT ENCODING的返回值在不同大版本间有差异7.0 之后 ziplist 全面换成 listpack看到listpack而不是ziplist是正常的别以为是实例配错了。这里有个容易忽略的点编码转换是单向的。listpack 转成 hashtable 之后即使你把元素删到只剩一个也不会自动转回去。所以一个曾经很大的 Hash删空之后用OBJECT ENCODING看仍然是 hashtable内存不会立刻降下来。要彻底回收只能删 key 重建或者用MEMORY USAGE确认后做一次重建迁移。2. String 和 Hash被误用最多的两个类型String 是所有人最先接触的类型也正因为简单被滥用到极致。我见过把整个对象序列化成 JSON 塞进 String 的写法也见过把几十个字段拆成几十个 key 的写法。Hash 则经常被当成小对象容器但它的 field 粒度设计才是真正影响内存账单的东西。2.1 String 的三个编码分界与 44 字节这条线embstr和raw的分界是 44 字节这个数字不是拍脑袋定的。redisObject占 16 字节sdshdr8头部占 3 字节加上结尾的\0占 1 字节一共 20 字节jemalloc 会按 64 字节的块来分配64 - 20 44正好是能塞进一个内存块的字符串长度上限。超过 44 字节就要额外分配一次内存多一次内存寻址。这个细节的实际意义在于如果你有大量短小的 key-value尽量把值控制在 44 字节以内。比如存一个短 ID、状态码、配置开关都远小于这个数但如果你存的是一个带时间戳的紧凑 JSON很可能刚好跨过这条线。我在一个计数场景里见过把 count 从整数改成带前缀的字符串为了区分业务结果 encoding 从 int 变成 raw几十万 key 的内存用量直接涨了一大截。String 的常用命令里有几个语义值得单独说清楚# 原子自增返回自增后的值 INCR page:view:20240501 INCRBY balance:1001 50 INCRBYFLOAT temperature 0.5 # 不存在才设置可作为最简单的分布式锁 SETNX lock:order:1001 1 # 带过期时间的原子写法6.2 之后推荐这个替代 SETNX EXPIRE SET lock:order:1001 1 NX EX 30 # 取值并设置新值原子操作 SET counter 10 GETSET counter 20 # 返回 10已弃用改用 SET counter 20 GET SET counter 30 GET # 返回 20 # 追加与范围操作 APPEND log step1; GETRANGE log 0 4 SETRANGE log 0 STEP注意INCR的上限是有符号 64 位整数9223372036854775807。超过会直接报increment or decrement would overflow不会溢出成负数。这一点在计数器场景里要留意虽然实际很难达到但如果你做过 bit 位运算把高位当标志位用就会撞上。SETNX和SET ... NX EX的差别不只是少敲一条命令。SETNX加EXPIRE是两步中间如果客户端崩了或者网络断了就会留下一个永不过期的锁 key直接死锁。SET key value NX EX seconds是单命令原子执行不存在这个窗口。这个坑我在早期项目里实实在在踩过一次当时是凌晨三点被叫起来手动删 key。2.2 Hash 的 field 粒度决定内存账单Hash 的价值在于把一组相关字段聚在一个 key 下同时支持单字段读写。相比把整个对象序列化成 StringHash 的优势是改一个字段不用回写整个对象相比拆成多个 keyHash 的优势是少了一层 key 的元数据开销每个 key 都有 redisObject、过期字典项、字典条目这些都是实打实的内存。用HSET存单个对象的写法HSET user:1001 name A同学 age 24 city 杭州 level 3 HGET user:1001 name HMGET user:1001 name age HGETALL user:1001 HINCRBY user:1001 level 1 HDEL user:1001 city HLEN user:1001 HEXISTS user:1001 name HKEYS user:1001 HVALS user:1001这里的关键判断是什么时候该用 Hash什么时候该拆成独立 key。我的经验是看字段的生命周期一致性。如果一组字段总是整体读写、一起过期、一起删除用 Hash 明显更省内存。如果某些字段需要独立设置过期时间那就不适合放 Hash因为 Redis 的过期时间只能设在 key 级别不能设在 field 级别。还有一个常见误区是 Hash 的 field 数量。hash-max-listpack-entries默认是 128超过之后整个 Hash 会转成 hashtable内存占用会比 listpack 高出不少因为每个 field-value 都要维护哈希表节点。如果你有一个 Hash 存了上千个 field那它在内存里的形态已经完全不是你以为的紧凑结构了。这种场景用MEMORY USAGE user:1001看一下实际占用往往会有惊喜。127.0.0.1:6379 MEMORY USAGE user:1001 (integer) 128 127.0.0.1:6379 MEMORY USAGE big:hash (integer) 104936提示HGETALL在 field 数量很大时是 O(N) 操作会一次性返回所有数据并占用网络带宽。field 上千的 Hash 建议改用HSCAN分批遍历或者干脆重新设计 key 的切分方式。3. List、Set、ZSet结构选型的三岔路口这三个类型经常被放在一起比较因为它们都能装多个元素。但它们的结构差异决定了适用场景完全不同List 是有序的双向链表底层是 quicklistSet 是无序去重集合ZSet 是带分数的有序集合底层是跳表加字典。选错了不是性能差一点的问题而是根本实现不了需求。3.1 List 做队列时的方向一致性List 做队列的经典写法是LPUSH进、RPOP出或者反过来。关键是进出方向必须相反否则就退化成栈了。这一点听起来简单但我在代码评审里见过不止一次两边都写LPUSH的实现测试环境数据少看不出问题线上就变成了后进先出消息顺序全乱。# 生产者从左边推 LPUSH queue:task task-001 LPUSH queue:task task-002 # 消费者从右边取先进先出 RPOP queue:task # 返回 task-001 # 阻塞版本队列空时最多等 5 秒避免空轮询 BRPOP queue:task 5BRPOP返回的是一个两元素数组第一个是 key 名第二个是值——很多人第一次用会直接拿返回值当字符串处理结果拿到的是数组的第一个元素key 名排查半天。这个细节在文档里写得很清楚但确实容易忽略。List 还有一个能力是范围操作和裁剪做最近 N 条这类需求非常顺LPUSH feed:1001 post-100 LTRIM feed:1001 0 99 # 只保留最新 100 条 LRANGE feed:1001 0 9 # 取最新 10 条 LLEN feed:1001 LREM feed:1001 0 post-50 # 删除所有等于该值的元素LTRIM这个命令值得单独记一下。它把 List 裁剪到指定范围范围外的元素全部删除而且时间复杂度只有 O(N)N 是被删除的元素数。做固定长度的消息流、操作日志、最近浏览记录用它比自己算长度再删要干净得多。3.2 Set 的集合运算与 SINTERSTORE 的时间复杂度Set 的核心价值是两个去重和集合运算。去重是SADD天然具备的集合运算是SINTER、SUNION、SDIFF这一组。SADD tag:post:1 redis cache db SADD tag:post:2 redis mq SISMEMBER tag:post:1 redis # 判断是否存在O(1) SCARD tag:post:1 # 元素个数 SINTER tag:post:1 tag:post:2 # 交集redis SUNIONSTORE result tag:post:1 tag:post:2 SMEMBERS tag:post:1 # 全量返回大集合慎用 SRANDMEMBER tag:post:1 2 # 随机取 2 个不删除 SPOP tag:post:1 2 # 随机弹出 2 个删除集合运算的时间复杂度是 O(N*M)N 是最小集合的大小M 是集合数量。当参与运算的集合很大时这个命令会长时间占用主线程。我见过一个抽奖场景用SINTER求两个几十万元素的集合交集单次执行接近一秒直接把整个实例的其他请求全挡住了。这种场景的正确做法是把大集合拆小、用SINTERSTORE把结果落到临时 key 上异步处理或者干脆把集合运算挪到离线任务里做。还有一个容易被忽略的行为SINTER的结果顺序是不确定的因为它基于哈希表遍历。如果你的业务依赖结果顺序得自己在外层排序。3.3 ZSet 的 score 设计与排行榜翻页ZSet 是 Redis 里我最喜欢的结构跳表加字典的组合让它在范围查询和单点查询上都是 O(logN)。排行榜是它的经典场景但真正写好排行榜难点在 score 的设计。最直白的写法是 score 就是分数ZADD rank:score 100 user:1 ZADD rank:score 95 user:2 ZINCRBY rank:score 10 user:1 ZREVRANGE rank:score 0 9 WITHSCORES # 前 10 名 ZREVRANK rank:score user:1 # 排名从 0 开始 ZSCORE rank:score user:1 # 查分数 ZCOUNT rank:score 90 100 # 分数区间计数问题出在同分排序上。多个用户分数相同的时候ZREVRANGE的顺序是按字典序member 的二进制比较来的不是按达到时间。业务上通常希望先达到的先排前面解决办法是把时间戳编码进 score整数部分存分数小数部分存一个反向的时间戳让早提交的分数略高。# 假设满分 100时间戳取反后归一化成小数 # 实际写法一般用 score 分数 * 10^10 (最大时间戳 - 当前时间戳) ZADD rank:score 1009999999999 user:1这种编码方式在数据量到百万级时要注意score 是 double只有 53 位有效精度分数部分占得太多会导致小数部分精度丢失出现明明同时提交却排错位的现象。稳妥的做法是时间精度只保留到秒或毫秒并且提前算好位数分配。分页也是排行榜的常见坑。ZREVRANGE key start stop的 start 很大时比如翻到第 10000 页跳表需要先走 start 步耗时是 O(logN M) 里的 M 部分。深度翻页的正确方式是用游标上一页最后一条的 score 作为下一次ZREVRANGEBYSCORE的起点ZREVRANGEBYSCORE rank:score (99.5 -inf WITHSCORES LIMIT 0 10这里的左括号表示开区间避免分数相同导致重复返回或漏返回。4. 遍历类命令KEYS 的替代方案与 SCAN 的真实行为这一节单独拎出来讲因为遍历是 Redis 使用中事故率最高的操作之一。我在不止一个项目里见过上线前用KEYS *检查数据、结果把实例打挂的情况而且几乎每次都是同一批人在同一个地方栽跟头。4.1 KEYS 为什么一执行就卡住整个实例Redis 处理命令的主线程是单线程的指命令执行这条路径KEYS的复杂度是 O(N)N 是整个库的 key 数量。也就是说当你有 500 万个 key 的时候执行一次KEYS *会扫描 500 万个 key 并构造返回结果这期间所有其他客户端的命令都排在后面等着。本地测试环境可能只有几千个 keyKEYS跑起来毫无感觉所以你根本意识不到危险。等上了生产几十万上百万 key一次KEYS就是几秒的完全阻塞超时、连接堆积、监控告警一起爆。注意KEYS在生产环境应该被视为禁用命令。Redis 提供了rename-command配置项可以直接把KEYS改名或者禁用掉比靠人自觉可靠得多。# 在配置文件中禁用危险命令 rename-command KEYS rename-command FLUSHALL rename-command FLUSHDB 4.2 SCAN 游标为什么不保证顺序也不保证不重复SCAN是KEYS的替代方案它用游标分批遍历每次只处理一小部分不会长时间阻塞。但它的行为有几个必须理解的点否则很容易写出错误的代码。127.0.0.1:6379 SCAN 0 MATCH user:* COUNT 100 1) 17 2) 1) user:1001 2) user:1002 3) user:2001返回的第一个元素是下一次的游标第二个是这批 key。游标回到0表示遍历结束。关键在于SCAN只保证从开始到结束期间一直存在的元素一定会被返回至少一次不保证顺序也不保证不重复。底层用的是反向二进制迭代扩容缩容时会有元素被重复访问。所以你的处理逻辑必须幂等不能假设每个 key 只会出现一次。COUNT参数也不是精确返回 COUNT 个而是一个提示值。实际返回数量可能多也可能少尤其在小集合上COUNT 100可能一次就把所有 key 返回了因为底层是编码在哈希表槽位上的遍历。一个正确的遍历模式大概长这样import redis r redis.Redis(host127.0.0.1, port6379, decode_responsesTrue) cursor 0 seen set() while True: cursor, keys r.scan(cursorcursor, matchuser:*, count200) for k in keys: if k in seen: continue seen.add(k) process(k) if cursor 0: break用seen集合去重只适合小规模几百万 key 时这个集合本身就吃掉大量内存。更实际的做法是让处理逻辑天然幂等比如写数据库用INSERT ... ON DUPLICATE KEY UPDATE或者写文件时按 key 排序后再落盘。另外SCAN只遍历当前库的 key。要遍历所有库得用SCAN配合SELECT或者直接用SCAN的TYPE参数过滤类型6.0SCAN 0 TYPE hash COUNT 5004.3 大 key 的发现与删除UNLINK 与分段处理比遍历更危险的是删除大 key。DEL一个包含几十万元素的 Hash 或 List释放内存的过程是同步的会阻塞主线程耗时可能达到几百毫秒甚至更久。而UNLINK做的事情是把 key 从键空间摘掉然后把内存释放交给后台线程异步处理主线程立刻返回。DEL big:hash # 同步释放可能卡住 UNLINK big:hash # 异步释放推荐UNLINK是 4.0 引入的现在应该成为删除大对象的默认选择。但要注意它只是把释放动作挪到后台如果短时间大量UNLINK后台线程也会堆积内存不会立刻降下来。发现大 key 的办法MEMORY USAGE只能一个个查效率太低。实际项目里我一般用SCAN配合MEMORY USAGE采样或者用redis-cli --bigkeysredis-cli --bigkeys -i 0.1-i 0.1表示每扫描 100 次 sleep 0.1 秒用来降低对线上实例的压力。这个命令会输出每种类型中最大的 key是接手陌生实例时的第一手资料。但它只找单个 key 最大找不出总占用最多的分布后者得靠MEMORY USAGE采样加统计。还有一点如果一个大 key 必须删但你不能接受后台释放的内存峰值更稳妥的做法是分段删把大 Hash 拆成多个小 Hash或者用HSCAN遍历一遍逐个HDEL每次删一批中间加 sleep。5. 三个偏门类型Bitmap、HyperLogLog、GEO 的适用边界这三个类型在实际项目里的使用频率远低于前五种但用对了能省掉大量内存用错了就是给系统埋雷。它们的共同点是都建立在前五种类型之上是特定场景的压缩封装。5.1 Bitmap 做签到表的位运算细节Bitmap 不是独立类型它就是 String只是把每个 bit 当独立开关用。签到场景是它的经典应用一个用户一个月的签到情况31 个 bit 就够了存成 String 也就 4 个字节。# 第 1 天签到offset 从 0 开始 SETBIT sign:1001:202405 0 1 SETBIT sign:1001:202405 4 1 # 查询第 1 天是否签到 GETBIT sign:1001:202405 0 # 统计本月签到天数 BITCOUNT sign:1001:202405 # 找到第一个没签到的位置 BITPOS sign:1001:202405 0 # 求两天都签到的天数按位与 BITOP AND result sign:1001:202405 sign:1001:202406 BITCOUNT result用 Bitmap 时最容易踩的坑是BITCOUNT的区间参数。它的start和end单位是字节不是位。所以你想统计第 0 到第 7 位刚好一个字节要写BITCOUNT key 0 0而不是BITCOUNT key 0 7。BITCOUNT sign:1001:202405 0 0 # 统计第 0-7 位 BITCOUNT sign:1001:202405 0 3 # 统计第 0-31 位4 个字节另一个坑是 offset 的上限。Bitmap 的最大 offset 是2^32 - 1也就是 512MB。如果你用一个很大的 offset 做稀疏标记比如用用户 ID 做 offset一条SETBIT key 100000000 1就会立刻分配 12.5MB 内存。稀疏场景千万别用 Bitmap用 Set 更合适。5.2 HyperLogLog 的 0.81% 误差意味着什么HyperLogLog 用来做基数统计去重计数最大特点是固定内存 12KB无论统计多少个元素。代价是有误差标准误差是 0.81%。PFADD uv:20240501 user:1 user:2 user:1 PFCOUNT uv:20240501 # 返回 2 PFMERGE uv:week uv:20240501 uv:20240502 PFCOUNT uv:week12KB 这个数字来自它的实现16384 个桶每桶 6 bit16384 * 6 / 8 12288 字节正好 12KB。误差公式是1.04 / sqrt(16384) ≈ 0.81%。这个误差意味着什么很多人在用之前没想清楚。如果你的 UV 统计是 100 万误差 0.81% 就是 8100 人作为趋势观察完全够用但如果你的业务要求精确到个位数比如计费那就不能用 HyperLogLog必须用 Set 或者数据库去重。还有一个细节PFADD的返回值是内部结构是否发生变化不是是否新增。所以你不能靠它判断某个元素是不是第一次出现。另外 HyperLogLog 的编码在数据量小时会退化成稀疏编码内存更小达到一定规模后转成稠密编码固定 12KB这个转换过程用OBJECT ENCODING能看到raw和hll的区别。5.3 GEO 的底层是 ZSet不是独立结构GEO 用来做地理位置查询常见命令是GEOADD、GEODIST、GEOSEARCH。GEOADD shop 120.15 30.28 shop:1 GEOADD shop 120.16 30.29 shop:2 GEODIST shop shop:1 shop:2 km GEOPOS shop shop:1 # 找出 5 公里内的店铺6.2 推荐 GEOSEARCHGEORADIUS 已标记弃用 GEOSEARCH shop FROMMEMBER shop:1 BYRADIUS 5 km WITHDIST WITHCOORD ASC它的底层是 ZSet经纬度通过 GeoHash 编码成一个 52 位的整数作为 score 存进 ZSetmember 就是地点名。所以你可以用 ZSet 的命令直接操作 GEO 数据ZRANGE shop 0 -1 WITHSCORES ZCARD shop ZREM shop shop:1这个结构认知有几个直接好处。第一GEO 的 key 和普通 ZSet 共享同一套内存和过期机制不用担心特殊处理。第二GeoHash 编码会有精度损失位置越靠近极地误差越大做精准地理围栏时要注意。第三因为底层是 ZSet它天然按 score 排序这也是GEOSEARCH ... ASC能直接按距离排序的原因。还有一个版本差异要注意GEORADIUS系列命令在 6.2 之后被标记为弃用官方推荐GEOSEARCH和GEOSEARCHSTORE。新项目直接用新命令老项目迁移时注意BYRADIUS和BYBOX的参数顺序跟老命令不一样。6. 线上环境里那些命令看着没错但不该用的场景前面讲的都是这个类型该怎么用这一节讲反向的哪些命令语法完全正确、本地跑也没问题但放到线上就是事故。6.1 RENAME 与过期时间的传导关系RENAME的语义是把源 key 改名成目标 key如果目标已存在就覆盖。这里有个细节经常被误解源 key 的过期时间会跟着一起搬到新名字上。SET src value EX 60 SET dst old TTL dst # -1永不过期 RENAME src dst TTL dst # 约 60继承了 src 的过期时间这个行为在大多数场景下是符合预期的但如果你用RENAME做原子替换配置这类操作就要确保源 key 的 TTL 是你想要的。更稳妥的做法是用SET直接覆盖或者用RENAMENX目标不存在才改名避免误覆盖。另外RENAME在 3.2 之前是 O(1) 的因为只是改指针但对大 key 来说现在版本里改名本身仍然很快问题不在这。真正的风险是目标 key 已存在时被覆盖的那个大 key 需要同步释放内存这时候跟DEL大 key 是一样的问题。6.2 MULTI 事务里的类型错误不会导致回滚这是 Redis 事务和关系型数据库事务最大的差别也是我见过最多误解的地方。MULTI SET counter 100 LPUSH counter oops # 对 String 执行 List 命令运行时错误 INCR counter EXECEXEC执行时SET会成功LPUSH报WRONGTYPE错误INCR继续执行成功。Redis 不会因为中间一条命令失败而回滚前面已执行的命令。Redis 官方文档说得很明确它只保证命令按顺序执行、不被其他客户端打断不保证原子性意义上的全成功或全失败。只有一种情况会让整个事务不执行命令在入队阶段就报错比如命令名写错、参数个数不对这时候EXEC会直接返回错误所有命令都不执行。这个区分很重要入队错误整体不执行运行时错误部分执行。所以用事务做先检查再修改是不可靠的。真正的原子性保障要靠 Lua 脚本脚本内部的所有命令是原子执行的-- 检查并自增类型不对就直接返回 local v redis.call(TYPE, KEYS[1]).ok if v ~ string and v ~ none then return redis.error_reply(WRONGTYPE) end return redis.call(INCR, KEYS[1])6.3 我踩过的几个具体坑最后分享几个真实踩过或接手时遇到的坑都是那种文档里写了但你不一定看的类型。第一个是TYPE和OBJECT ENCODING的区别。早期排查问题时我一直用TYPE看到string就以为是简单字符串结果那个 key 是 HyperLogLog用普通字符串命令操作直接报错。TYPE返回的是逻辑类型OBJECT ENCODING返回的是物理编码排查问题两个都要看。第二个是GETSET的弃用。这个命令在 6.2 之后被标记弃用推荐用SET key value GET。后者功能一样但在集群模式下行为更一致而且在参数组合上更灵活。第三个是EXPIRE的精度。EXPIRE key 1是 1 秒后过期但 Redis 的过期删除是惰性加定期清理的组合key 到期不等于立刻消失。所以用EXPIRE做分布式锁时锁的释放时间可能比你预期晚一点。这也是为什么锁的续期逻辑要做而且续期要比 TTL 提前不少。第四个是SCAN搭配MATCH的性能。MATCH是在服务端过滤的也就是说即使你的 pattern 只匹配 1% 的 keySCAN仍然会遍历所有槽位只是返回时过滤掉。所以MATCH加上一个很窄的 pattern 并不会让扫描变快只是返回变少。大数据量下如果真的只需要某一类 key更好的办法是设计 key 时加前缀分区或者用专门的索引 key比如 Set维护清单。第五个是TTL返回值的三态。-2表示 key 不存在-1表示存在但没设过期时间正整数才是剩余秒数。我在代码里见过把-1当成即将过期来判断的逻辑结果永不过期的 key 被当成要过期的处理做了一堆无用的续期操作。这些坑单独看都不复杂但组合在实际业务里就是事故。我现在的习惯是任何涉及遍历、删除、批量操作的命令先在测试环境用接近生产的数据量跑一遍看耗时和内存变化再决定要不要上线。数据量是 Redis 里最容易被低估的变量一万个 key 和一百万 key同一条命令的表现在两个世界。如果要把这篇的内容收成一条可操作的建议那就是先花半小时把OBJECT ENCODING、MEMORY USAGE、SLOWLOG GET这三个命令用熟。它们不解决业务问题但能让你在敲下任何一条命令之前对它的代价心里有数。后面再聊持久化和主从复制的时候这些基础认知会直接决定你能不能看懂 RDB 文件里那堆编码标记。