Redis数据类型选型与底层编码：使用场景、内存优化与性能实践

Redis 这个家伙，很多人第一次接触它都是从一句SET key value开始的，觉得它就是个"跑得快的缓存"。可真到了线上，一个排行榜做不出来、一个签到系统内存飙到几十 G、一个限流逻辑被并发打穿，才发现问题根本不在"快不快"，而在数据类型选得对不对。这篇聊的就是 Redis 数据类型和使用场景这两件事——五种基础类型怎么选、四种扩展结构什么时候该上、底层编码在什么阈值上悄悄换掉、以及换掉之后内存和性能会发生什么变化。不管你是刚把 Redis 装进项目里、还在到处翻命令手册的新手，还是已经写过几套缓存方案、但一直没搞明白"为什么我的 Hash 反而更占内存"的老手，这里面的细节大概率能帮你省下几次线上排查的深夜。

1. 先把数据类型当成一道结构选型题

1.1 五种基础类型，八种底层编码

很多人背过"String、Hash、List、Set、ZSet"这五个词，就以为自己掌握了 Redis 的数据类型。这只能算记住了对外接口，真正决定内存占用和操作复杂度的是底层编码。同一个 Hash，元素少的时候它是一块连续内存里的紧凑数组，元素多的时候它变成了一张散列表；同样是 Set，全是整数时它是一棵有序整数集合，掺了字符串之后可能变成紧凑列表，再大就变成散列表。对外命令一模一样，背后的内存布局和单次操作耗时完全是两回事。

我习惯把这件事类比成装箱子：小件物品塞进一个分隔好的收纳盒（listpack），一目了然、拿取也快；东西多到收纳盒装不下，就得换成带索引的货架（hashtable / skiplist），查找依然快，但每个格子本身要占地方，整体空间开销就上去了。Redis 的设计哲学就是"小数据用紧凑结构换内存，大数据用索引结构换速度"，这个取舍贯穿了几乎所有类型。

具体的编码对照，我整理成一张表，方便你随时回查：

这张表值得打印出来贴在显示器边上。因为绝大多数"Redis 内存莫名其妙涨了"的问题，答案都在这张表的某一行里——你以为是数据变多了，其实是编码降级了，每一个元素从"挤在一起"变成"各占一间房"，内存翻三五倍很正常。

1.2 为什么类型选错比选错存储更伤

选错存储引擎，通常表现为"慢"，你能通过加机器、加索引救回来；选错 Redis 数据类型，往往表现为"慢 + 内存爆炸 + 数据不一致"三件事同时发生，而且救起来很麻烦。我见过一个很典型的例子：某项目把用户画像的十几个字段拆成十几个独立的 String key，前缀都是同一个用户 ID。单看每个 key 都很小，但用户量上到千万级之后，key 数量直接破了亿，光是 key 本身的字符串和字典项开销就吃掉了一半以上的内存预算。

后来改成一个大 Hash 存同一用户的字段，字段总数远低于 128、单值也都在 64 字节以内，全程走 listpack 编码，内存直接降到原来的三分之一左右。这不是什么高级技巧，纯粹是把"同一批需要一起读写的数据"放进了同一个容器里。

反过来也有选错的：有人拿 List 做"按用户维度存储最近浏览记录"，每个用户一个 List，结果用户数一多，key 数量爆炸不说，每个 List 还都带着自己的元数据开销。这种场景其实更适合用 ZSet 做全局时间线再按用户维度过滤，或者干脆用 Hash 存"用户 → 最近 N 条记录 JSON"。

选型的核心判断标准其实就三条：这批数据是不是总被一起访问、是不是需要按某个维度排序或去重、单个容器的元素数量级大概是多少。想清楚这三条，类型基本就定了。

注意：编码转换基本是单向的。listpack 升级成 hashtable 之后，即使你把元素删回 10 个，它也不会自动降回 listpack。想回到紧凑编码，只能把数据读出来、删 key、重新写一遍。

2. 逐个拆解：每种类型该在什么场景出现

2.1 String：缓存只是它最无聊的用法

String 是唯一一个能直接跟"字节"打交道的类型，这也决定了它的能力边界远比"缓存对象"宽。最基础的用法当然是缓存：把序列化后的对象塞进去，配合EX过期时间。这里的经验是——序列化格式的选择直接影响内存和兼容性。JSON 可读性好、跨语言方便，但体积大、解析慢；MessagePack 或 Protobuf 体积小很多，代价是排查问题时得先反序列化才能看懂。我一般的做法是：调试期用 JSON，稳定后如果单 key 体积超过几 KB，再考虑换紧凑格式。

String 真正有意思的地方是它的原子计数能力。INCR、INCRBY、INCRBYFLOAT都是单命令原子操作，天然适合做各种计数：文章阅读数、接口调用量、库存扣减的预扣计数。做库存预扣的时候有个细节要注意，DECR在值变成负数时不会报错，它会老老实实返回 -1。所以库存场景一般要先SET好初始值，然后用 Lua 脚本把"判断 + 扣减"包成一个原子操作，或者用DECR之后检查返回值，如果小于 0 再INCR回滚——后者在高并发下会产生大量无意义的回滚操作，不如 Lua 干净。

还有一个被严重低估的用法：分布式锁的底座。SET key value NX PX 30000这一条命令同时完成了"不存在才设置"和"设置过期时间"两件事，是加锁的标准姿势。用SETNX再加EXPIRE是错误示范，因为两条命令之间如果进程挂了，锁就永远不过期了。释放锁的时候必须校验持有者，否则可能把别人的锁删掉：

-- 释放锁：只有 value 匹配才删除 if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end

这个脚本看着简单，但少一行判断就是一次生产事故。我踩过这个坑：早期版本没校验 value，结果 A 请求因为超时被自动释放锁，B 拿到了锁，A 执行完把 B 的锁删了，两个请求同时操作同一份数据，对账对了整整两天。

2.2 Hash：对象缓存的省内存写法，以及它的边界

Hash 最适合的场景是"一个逻辑对象的多个字段"。用户信息、商品属性、配置项这类数据，字段数在几十个以内、单字段值不大的，用 Hash 存比拆成多个 String 划算得多——省的是 key 本身的重复开销。一个 key 名user:profile:1000123大概 22 字节，加上 redisObject 和 dictEntry 的元数据，实际占用可能在 80 到 100 字节之间。十个字段拆十个 key，光这部分固定开销就是 800 到 1000 字节；合成一个 Hash，固定开销只付一次。

但 Hash 不是万能的。它的短板在于过期只能整 key 过期，不能给单个 field 设过期时间。这个限制在实际项目里会咬人：比如你想存"用户最近一次操作的各类时间戳"，每个字段的过期时间都不一样，Hash 就做不了。这时候要么拆成多个 String，要么用 ZSet 把"字段名"当成员、"时间戳"当分数，靠分数来做逻辑过期判断。

还有一个反直觉的点：当字段数超过 128 之后，Hash 会从 listpack 转成 hashtable，内存会有一个明显的台阶式上涨。我做过一次实测，同一个用户对象，128 个字段时是整个 listpack 一块内存，129 个字段时变成哈希表，单 key 内存从 8KB 左右跳到 20KB 以上。所以如果你的业务模型字段数会持续增长，要么提前规划好拆分成多个 Hash（比如按"基本信息""偏好设置""统计数据"分三组），要么干脆在应用层做序列化后存 String。

删除大 Hash 也是一门学问。一个几十万字段的 Hash，直接DEL会造成主线程阻塞，因为释放内存是同步的。正确的做法是用UNLINK（异步释放），或者用HSCAN分批HDEL：

# 分批删除，每批 1000 个字段 HSCAN big:hash 0 COUNT 1000 HDEL big:hash field1 field2 ...

UNLINK在 4.0 之后就有了，能用就用它，省心。

2.3 List：轻量队列的取舍与时间的坑

List 最经典的用法是简易消息队列：LPUSH进、BRPOP出，阻塞式弹出还能避免空轮询。配合BRPOPLPUSH（或者 6.2 之后的BLMOVE）还能做"处理中队列"，消费者取出消息的同时把它挪到另一个 List，处理成功再删掉，进程挂了消息还在备份 List 里，可以人工或定时任务补回来。这套方案在消息量不大、对可靠性要求不是极致严格的场景里非常好用，省掉了一整套消息中间件的运维成本。

但它有几个明显的天花板，得提前知道。第一，没有消费组概念，多个消费者抢同一个 List，一条消息只会被一个人拿到，做广播很麻烦。第二，没有 ACK 机制，靠的是你自己用备份 List 模拟。第三，LRANGE这类按索引访问的命令在大 List 上是 O(N) 的，别拿它做"取第 50000 到 50100 条"这种操作。

List 的另一个常用场景是"最新 N 条"：LPUSH加LTRIM 0 99，永远只保留 100 条，内存可控。这个组合非常好用，比如"最近 100 条操作日志""最新 50 条评论"。要注意LTRIM之后老数据是真的没了，如果你还需要历史数据，就得另存一份。

还有一个坑值得单独说：用 List 做队列时，如果生产速度长期大于消费速度，List 会无限增长，最后把内存吃光。我见过一次把 Redis 内存打满的事故，根因就是下游消费服务挂了两小时，上游还在往里推。稳妥的做法是给这个 key 设一个长度上限，或者监控LLEN做告警。Redis 本身不提供队列长度限制，得靠应用层或者定时任务去LTRIM。

2.4 Set 与 ZSet：去重和排序的两把刀

Set 的语义特别干净：无序、去重、支持交并差。它最实用的三个场景我按使用频率排一下。

第一个是去重统计。比如"某篇文章今天被哪些用户看过"，SADD article:1001:uv user_id，SCARD拿数量。数据量在几万以内完全没问题，但它有个明显短板：如果 UV 是百万级，Set 会把每个 user_id 都存下来，内存按成员数线性增长。这种时候就该换 HyperLogLog 了，后面会讲。

第二个是关系判断，也就是SISMEMBER。比如"用户是否在某个白名单里""这个 IP 是否被拉黑"，O(1) 查询，非常快。第三个是交并差，SINTER找共同关注、SDIFF找"我有他没有"的推荐候选。要注意这些命令的复杂度跟参与集合的元素总数相关，两个十万级的 Set 做SINTER会有明显延迟，最好放在离线任务里跑，别放在请求链路上。

ZSet 是 Redis 里最"贵"也最强大的类型。每个元素除了成员本身，还要存一个 8 字节的 double 分数，再加上 skiplist 的多层指针，单元素开销比 Set 大不少。但换来的能力是"按分数排序 + 按分数范围查询 + 按排名查询"，这三件事在业务里出现频率极高。

排行榜是教科书级用法：ZINCRBY rank:2024 1 user:1001，ZREVRANGE rank:2024 0 9 WITHSCORES取前十。这里有个细节，ZREVRANGE已经在 6.2 被标记为废弃，新写法是ZRANGE rank:2024 0 9 REV WITHSCORES。老命令还能用，但新项目建议直接用新语法。

延迟队列是 ZSet 另一个高价值用法：成员是任务 ID，分数是执行时间戳，消费者用ZRANGEBYSCORE key 0 now LIMIT 0 10捞到期任务。这里要注意原子性——捞出来到删掉之间如果有并发消费者，同一条任务可能被处理两次。解决办法是用 Lua 脚本把"查询 + 删除"合并成一步，或者用ZPOPMIN系列（但它只能弹分数最小的，不能按分数范围弹）。

2.5 位图、HyperLogLog、GEO、Stream：四个被低估的专用结构

Bitmap是在 String 上做位操作，本质还是 String，只是用SETBIT/GETBIT/BITCOUNT去操作某一位。签到是最典型的场景：每个用户一个 key，一年 365 天，第 N 天就把第 N 位置 1。存储成本低到夸张——一年才 46 个字节。BITCOUNT key一次拿到总签到天数，GETBIT key n判断某天是否签到。这里有个常见的坑：BITCOUNT支持按字节范围统计（BITCOUNT key start end），单位是字节不是位，想统计某个月就得自己算字节偏移。更省事的做法是每月一个 key，key 名里带月份，offset 用"日 - 1"，逻辑清爽很多。

HyperLogLog是用来做基数估算的，标准误差 0.81%，固定占用约 12KB。它只告诉你"大概有多少个不同的值"，不告诉你具体是哪些。UV 统计、搜索关键词去重计数这类场景用它是绝配。我做过对比：一个百万级 UV 的 Set 大概占几十 MB，同样的数据用 HLL 稳定在 12KB 上下，差了三个数量级。代价是它不能查单个元素是否存在，也不能列出成员。所以判断标准很简单：你只需要数字，不需要明细，就用 HLL。

GEO底层其实是 ZSet，Redis 把经纬度编码成一个 52 位的整数作为分数存进去。GEOADD存位置，GEOSEARCH按半径或矩形范围查。附近的人、门店距离排序都能用。注意它的精度在城市级别完全够用，但别指望它做米级的精确定位。另外范围查询的复杂度跟范围内元素数量相关，范围开得太大一样会慢。

Stream是 5.0 引入的，算是官方给的"正经消息队列"。它补上了 List 缺的那几块：消费组（XGROUP）、ACK（XACK）、待处理列表（XPENDING）、消息回溯（按 ID 范围读）。如果团队不想为了一个轻量场景引入完整消息中间件，Stream 是很务实的选择。它的内存模型是 rax 加 listpack，消息堆积多了会转成更大的节点，需要关注XTRIM或者MAXLEN参数，避免无限堆积。

3. 编码转换的账，得自己算一遍

3.1 阈值参数怎么调，调了会发生什么

前面那张表里的默认阈值不是拍脑袋定的，128 个元素、64 字节单值这个组合，大致对应"listpack 遍历开销还能接受、内存收益还明显"的平衡点。但默认值不一定适合你的业务，得结合实际情况调。

判断要不要调，我一般看两个信号。第一，单 key 的MEMORY USAGE结果是否明显超出预期。比如你预计一个 Hash 存 200 个字段应该占 20KB，实测 60KB，那就是编码降级了。第二，OBJECT ENCODING的输出是否符合预期。这条命令很轻，线上随时可以查：

OBJECT ENCODING user:profile:1000123 # 输出可能是 listpack 或 hashtable MEMORY USAGE user:profile:1000123 # 输出该 key 占用的字节数

如果发现某个业务的 Hash 字段数经常在 130 到 200 之间徘徊，每次都触发降级，有两个选择：把字段拆成两个 Hash，或者把hash-max-listpack-entries调大到 256。后者的代价是 listpack 变大之后，单次HGET需要在更长的紧凑数组里做线性扫描，CPU 会略微上升。这是个典型的空间换时间（或时间换空间）的取舍，没有标准答案，只能压测。

调参还有个大前提：这些配置改完之后，已经存在的 key 不会立刻重新编码，要等它们被修改或者重建。所以线上调参通常配合一次数据迁移，或者干脆接受"新数据用新配置、老数据慢慢过期"。

提示：config set改的参数在重启后会失效，务必同步写进配置文件，否则下次发布就是一次"悄悄回滚"。

3.2 内存估算：一个签到系统到底要多少内存

光讲理论容易飘，拿个具体场景算一遍更实在。假设要给 1000 万用户做每日签到，保留一年数据。

方案 A：每个用户一个 Bitmap，一年 365 位。位图本身约 46 字节。但每个 key 还有额外开销：key 名字符串（sign:1000123大约 13 字节）、redisObject 头（约 16 字节）、dictEntry（约 24 字节）、过期时间记录（如果设了 EXPIRE 再加约 16 字节）。粗算下来单个 key 的固定开销在 70 字节左右。总计约 116 字节 × 1000 万 ≈ 1.16GB。

方案 B：按"用户 + 月份"拆 key，每月一个 Bitmap，只存 31 位。位图约 4 字节，但 key 数量变成 1000 万 × 12 = 1.2 亿，固定开销 70 字节 × 1.2 亿 ≈ 8.4GB。明显更差。

方案 C：反过来，全局一个 Bitmap，用用户ID * 365 + 天数作为 offset。总位数 = 1000 万 × 365 = 36.5 亿位 ≈ 457MB。固定开销只付一次，非常省。但问题来了：单个 Bitmap 太大，BITCOUNT全量统计会很慢，而且这个 key 是典型的超大 key，迁移和删除都很痛。

所以实际项目里我倾向于方案 A 的变体：按用户分 key，但用 Hash 存多个月份的位图——不对，Hash 的 value 存位图不直观。更常见的做法还是方案 A，接受 1GB 左右的内存，但要注意这是"稀疏分配"的，用户 ID 不连续时 Redis 不会预分配，实际占用取决于最大值。

这几种方案的对比：

算这笔账的意义不在于选哪个，而在于让你意识到：在 Redis 里，key 的数量本身就是成本。很多"内存不够"的问题，本质是 key 太多而不是数据太大。

4. 落地实操：把排行榜、签到、限流串起来

4.1 场景设计与命令落地

假设要做一个小型内容社区的活动页，需要三样东西：实时人气榜、每日签到、接口限流。三个需求刚好对应三种类型，串起来讲比较有代入感。

人气榜用 ZSet。用户给内容点赞时ZINCRBY rank:activity:2024 1 content:8821，取榜单用ZRANGE rank:activity:2024 0 49 REV WITHSCORES。想查某个内容排第几，用ZREVRANK rank:activity:2024 content:8821，返回值从 0 开始，展示时记得加 1。榜单需要定期清零的话，别用DEL之后重建，会造成短暂的空窗期，更好的做法是 key 名带上周期（比如按天或按活动期），新周期自然就是新 key，老 key 设个过期时间自动回收。

签到用 Bitmap。这里有个细节值得展开：offset 怎么算。如果按"月内第几天"，那就是日期 - 1，范围 0 到 30；如果按"年内第几天"，范围 0 到 364。我倾向月内，因为BITCOUNT统计当月签到天数很方便，而且单 key 小、过期好管理。

# 用户 1000123 在 3 月 15 日签到，offset = 15 - 1 = 14 SETBIT sign:1000123:202403 14 1 # 查 3 月总共签到了几天 BITCOUNT sign:1000123:202403 # 查 3 月 15 日是否签到 GETBIT sign:1000123:202403 14 # 给这个月的 key 设置 40 天后过期 EXPIRE sign:1000123:202403 3456000

连续签到天数的计算就得靠应用层了，从当天往前逐位GETBIT，遇到 0 就停。数据量大时可以用BITFIELD批量读一段位，减少往返次数。

限流用 String 加 Lua。最简单的固定窗口限流是INCR加EXPIRE，但这两条命令之间不是原子的，第一次请求如果INCR之后没来得及EXPIRE，这个 key 就永不过期了。所以必须用 Lua 包起来：

-- 固定窗口限流：每分钟最多 100 次 local key = KEYS[1] local limit = tonumber(ARGV[1]) local window = tonumber(ARGV[2]) local current = redis.call('INCR', key) if current == 1 then redis.call('EXPIRE', key, window) end if current > limit then return 0 end return 1

固定窗口的问题是"窗口边界突刺"——第 59 秒打满 100 次，第 61 秒又打满 100 次，两秒内实际过了 200 次。要更平滑就得上滑动窗口，用 ZSet 存每次请求的时间戳，ZREMRANGEBYSCORE清掉窗口外的，ZCARD判断是否超限。代价是每个请求都要往 ZSet 里写一条，内存和 CPU 开销都比固定窗口大一个量级，只适合对精度要求高的接口。

4.2 容量估算与参数校验

上线前我习惯做一次粗算，把最坏情况想清楚。排行榜按 10 万条内容、每条平均被赞 50 次算，ZSet 的成员是 10 万个。ZSet 单成员的开销大概是成员字符串 + 分数 8 字节 + skiplist 指针（平均 1.33 层，每层两个指针，约 20 字节）+ 字典项约 24 字节。假设成员名平均 15 字节，单个成员约 70 到 90 字节，10 万成员大概 8MB 左右。这个量级完全不用担心。

签到按前面算的，1000 万用户约 1.1GB，这就得认真对待了。如果 Redis 实例总内存只有 4GB，签到就占了四分之一，再加上缓存、队列，很容易触发淘汰。这时候要么单独部署一个实例专门放签到，要么压缩用户规模、只保留活跃用户。把不同生命周期的数据放在同一个实例里，是很多内存问题的根源——缓存可以随便淘汰，签到数据丢了就是事故，两者的淘汰策略诉求根本冲突。

限流的 key 数量取决于维度。按用户 ID 限流，1000 万用户就是 1000 万个 key；按接口限流，可能只有几十个 key。前者的固定开销又是几百 MB 级别。所以限流维度要克制，能按 IP 或接口维度做的，别一上来就按用户维度。

5. 踩坑实录：那些类型用错引发的故障

5.1 大 key 与热 key：两个方向相反的麻烦

大 key 指的是单个 value 太大，比如一个几百万元素的 ZSet、一个几十万字段的 Hash、一个几十 MB 的 String。它的危害不在于读写慢（虽然确实慢），而在于阻塞主线程。Redis 处理命令是单线程的，一次HGETALL一个几十万字段的 Hash，或者DEL一个巨型 key，这期间所有其他请求都得排队。表现出来就是监控上一条尖锐的延迟毛刺，几秒到几十秒不等。

排查大 key 有几个手段。redis-cli --bigkeys可以扫一遍给出每种类型的最大 key，但它基于SCAN，对线上有轻微压力，建议在低峰期跑。更精细的是用MEMORY USAGE逐个查，或者开latency monitor抓慢命令。我一般先用--bigkeys定位类型，再针对性SCAN那个前缀。

治理大 key 的思路就三条：拆分、异步删除、加过期。拆分是把一个大 Hash 按字段前缀拆成多个，比如user:profile:shard:0到shard:9，用字段名的哈希取模决定放哪个。异步删除用UNLINK。加过期是让数据自然衰减，别让它无限长。

热 key 是另一个方向：单个 key 的访问量过高，把单个节点的 CPU 打满。比如秒杀商品的库存 key、爆款内容的详情缓存。这时候问题不是内存而是流量倾斜。常见解法有三层：本地缓存挡一层（用 Caffeine 之类，注意设置短过期和主动失效）、key 加随机后缀拆成多份读、读写分离把读压力分散到副本。

5.2 过期、淘汰与一致性的连锁反应

过期时间这件事，有几个细节经常被忽略。第一，Redis 的过期是惰性删除加定期删除的组合，不是到点就立刻消失。所以一个 key 过期了，GET它会返回空（惰性删除触发），但你不访问它，它可能还占着内存一段时间。第二，在 RDB 持久化或主从同步的场景下，过期 key 的处理有额外逻辑，从库不会主动删除过期 key，要等主库的删除命令同步过来。这意味着从库上可能读到"逻辑上已过期但还存在"的数据，应用层要能容忍。

淘汰策略的选择直接影响故障形态。noeviction是最安全的——内存满了就报错，不会丢数据，但会让写请求全部失败。allkeys-lru适合纯缓存场景，但要注意 LRU 在 Redis 里是近似实现，采样几个 key 挑最久未用的淘汰，不是精确的。volatile-lru只淘汰设了过期时间的 key，如果所有 key 都没设过期，这个策略等于noeviction，很容易被忽略。

注意：把"绝对不能丢的数据"和"可以随便淘汰的缓存"放在同一个实例、用同一个淘汰策略，是设计上的硬伤。该拆实例就拆，别省那点资源。

一致性方面，缓存和数据库的同步策略老生常谈，但跟数据类型结合起来看会清楚很多。String 缓存整个对象，更新时直接覆盖，简单但可能覆盖掉并发写入；Hash 支持只更新单个字段，粒度更细，但多字段更新不是原子的，要配合HSET的多字段语法或 Lua。我的经验是：读多写少、整体替换的用 String；字段独立更新、部分读取频繁的用 Hash。

5.3 常见问题速查表

6. 几个我反复验证过的实操习惯

6.1 上线前先跑一遍编码检查脚本

我现在做任何涉及 Redis 的新功能，都会在测试环境跑一个很小的检查脚本：灌入生产量级的数据，然后逐个OBJECT ENCODING和MEMORY USAGE，把实际占用跟预估对一遍。这个动作花不了半小时，但能提前发现 80% 的内存问题。

import redis r = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True) def inspect(key): enc = r.object('encoding', key) size = r.memory_usage(key) ttl = r.ttl(key) print(f"{key} | encoding={enc} | {size} bytes | ttl={ttl}") for k in r.scan_iter(match='user:profile:*', count=100): inspect(k) break

这类脚本的关键是用真实数据形态灌，别用a、b、c这种短字符串凑数。字段值的长度直接影响是否越过 64 字节的阈值，用假数据测出来的结论往往是错的。

6.2 命名规范比命令熟练度更重要

Redis 没有表结构，key 名就是全部的 schema。我的习惯是业务:对象:标识[:维度]，比如sign:1000123:202403、rank:activity:2024。这样做的好处是SCAN时能按前缀精确圈定范围，做批量治理、批量过期、批量迁移都方便。

反面教材是把 key 写成user_1000123_sign_202403，前缀被用户 ID 打断，想按业务维度扫就得多写好几层匹配逻辑。还有把随机数放在前缀前面的，那就彻底没法批量操作了。

另外，key 长度也要控制。一个 100 字节的 key，在千万级数量下光 key 名就是 1GB。能用短标识就别用长单词，能用数字 ID 就别用完整路径。

6.3 什么时候该果断放弃 Redis

最后说点逆向经验。Redis 很好用，但它不是所有"快"的问题的答案。遇到下面几种情况，我会优先考虑换方案而不是硬扛：

需要复杂查询的（多条件组合过滤、聚合统计），老老实实上数据库或者搜索引擎，别在 Redis 里用多个 Set 做交集模拟 SQL 的WHERE。数据量超过单机内存一半的，考虑分片或者换存储，单实例撑到极限之后运维成本会指数上升。需要强事务和持久化保证的，Redis 的持久化是"尽量不丢"，不是"绝对不丢"，账务类数据别只放这里。

我在一个项目里做过统计口径的迁移：一开始用 Set 存每天的活跃用户做交集分析，数据涨到千万级之后内存顶不住，后来改成每天落一份离线明细，Redis 只保留当天的 HyperLogLog 做实时大屏。实时数字有 1% 以内的误差，业务完全能接受，内存从几十 GB 降到几百 MB。这个取舍当时讨论了很久，结论其实很简单：先想清楚这个数字要精确到什么程度，再决定用哪种结构。

真正把 Redis 用顺手，靠的不是背命令，而是每次动手前问自己三句话：这批数据会不会一起读写、元素规模大概在哪个量级、丢了能不能接受。想明白这三个，类型、编码、过期、淘汰这些选择基本都会自己浮出来。