企业官网建设流程全解析

1. 从一次内存告警说起：数据类型选错有多可怕

1.1 那次线上事故的具体经过

我之前维护过一个电商类的练手项目，用户购物车数据用的是最偷懒的存法：把整个购物车对象序列化成 JSON 字符串，塞进一个 String 类型的 key 里，key 的命名类似cart:用户ID。前期流量小，一切正常，200 万用户在线、数据量上来之后，Redis 内存直接飙到接近 4GB，运维那边内存告警邮件一封接一封。那段时间我每天都在删过期数据、调 maxmemory 策略，但治标不治本。

后来认真复盘才发现，单条购物车 JSON 大概 800 字节，里面有五六次重复出现的字段名，比如 skuId、quantity、selected 这种。200 万条数据下来，光是重复的字段名和 JSON 语法符号就吃掉了一大块内存。换成 Hash 类型之后，整个存储量降到了 1.2GB 左右，key 粒度不变，但把每个 sku 作为 field、数量作为 value，彻底告别了 JSON 序列化和反序列化的开销。这个案例让我意识到一个核心问题：Redis 的数据类型从来不是"存什么"的问题，而是"为了这个数据特征，你愿意付多少内存和 CPU 成本"的问题。

1.2 数据类型选型的本质：成本模型

说到 Redis，很多人第一反应是"缓存"，第二反应是"支持五种数据结构"。但如果你只在面试里背过 String、Hash、List、Set、ZSet 的定义，遇到真实业务需求时大概率会做出最懒但也最贵的选择——全用 String。

我的经验是把类型选型看作一个三元成本模型：

• 内存成本：数据实际占用的字节数，包括 key、value、底层编码带来的额外开销。
• 时间成本：单次读写的 CPU 耗时，尤其要考虑集合类型的渐进式遍历耗时。
• 开发成本：代码复杂度、可维护性、团队里其他人能不能一眼看懂。

比如购物车场景，String JSON 的开发成本最低，但内存成本和时间成本都很高；Hash 的开发成本只高一点点，换来的却是内存大幅下降、还能单独改某个字段的 quantity 而不需要整个重写。后面你会发现，几乎每一种 Redis 类型，都有它"不可替代的理由"，也都有它"被过度使用的死穴"。

这篇文章我打算按实战维度来梳理：基本类型各自的边界在哪、哪些类型最容易搞混、进阶类型在什么场景下才是真正的答案、底层编码怎么影响你的内存账单，最后附一张我踩过坑之后总结的检查清单。如果你已经在项目里用 Redis，只是没系统想过"为什么用这个类型"，这篇整理应该能帮上忙。

2. 五种基本类型的使用边界与典型场景

2.1 String：别什么都往字符串里塞

String 是 Redis 最基础的类型，底层是动态字符串（SDS），支持的东西看起来最简单，其实最容易误用。它的可靠场景我总结了四类：

• 缓存简单值：验证码、token、接口返回的快照数据，一次写入多次读取，存 String 是完全正确的。
• 计数器：INCR、DECR 是天然原子操作，适合点赞数、访问量、库存扣减。这里要注意 INCR 在 64 位有符号整数范围内是安全的，别拿它做需要精确到小数点的统计。
• 分布式锁：SET NX EX 组合可以模拟一把简单锁，很多人忽略的是 value 必须带唯一标识，释放锁时要先比较再删除，防止误删别人的锁。这个属于用法问题，但 String 是承载它的默认类型。
• 位图基础能力：SETBIT/GETBIT 其实也在 String 上操作，不过一般把它单列为 Bitmap 来讨论，后面会说。

我见过最典型的误用是把对象直接 JSON.stringify 后塞进 String，而且是一个大对象带嵌套结构。问题是：

• 每次只要改其中一个字段，就得把整个对象取出来反序列化、改完再序列化写回去，在并发场景下还容易互相覆盖。
• 字段名在每一条数据里都重复存储，内存开销非常大。购物车那个例子就是这么翻车的。
• 完全没有利用 Redis 的服务端计算能力，比如对某个字段做自增，你根本做不到，只能读改写。

如果只是存"过了几分钟就丢的临时值"，String 一点问题都没有；如果你的数据有结构、有字段级别的更新需求，先停下来想想 Hash。另外注意吃透几个基础命令的语义，比如 SETEX 的原子性、SETNX 只做"不存在才设置"，这些在业务逻辑里一旦用错，代价通常不是内存而是数据正确性。

2.2 Hash：最被低估的类型

Hash 在五种基本类型里最像"对象"：一个 key 下面挂了多个 field-value。绝大多数"一个用户/一个商品/一台设备对应一堆属性"的场景，Hash 都是第一选择。原因很简单：

• field 可以单独增删改，HSET 只改某个字段，不需要全量读取。
• HINCRBY 可以对单个字段做原子自增，比如商品库存、用户积分，天然适合。
• 内存上相比 String JSON 省很多，尤其 field 名是短字段时，优势非常明显。

拿购物车再举例：key 是cart:1001，field 是 skuId，value 是数量。用户修改某个商品的数量，只需要 HINCRBY 或者 HSET 一个字段；结算时 HGETALL 拉出整个购物车，字段到数量天然是个 Map，几乎不用转换。换成 String JSON，全量读改写每次都逃不掉。

Hash 也不是没有坑，这里提三个：

第一，field 数量不能无限膨胀。一个 Hash 的 field 如果到了几十万甚至几百万，HGETALL 和 HSCAN 都会有问题。HGETALL 一次返回全部字段会阻塞 Redis 单线程，这就是典型的大 key 事故。field 多的时候要用 HSCAN 分批取，或者从设计上拆 key。

第二，field 值不要塞大字符串。一个 field 塞一个几 MB 的 base64 内容，HGET 同样会阻塞。Hash 适合"属性多但每个值小"的场景，不是大对象收纳箱。

第三，过期时间只能到 key 级别。Hash 的 field 没有独立 TTL，如果你需要"某个字段几分钟后自动消失"，要么定期清理，要么干脆用 String key 单独存。

2.3 List：队列用法与误用

List 的本质是双向链表（在 3.2 之前还有 ziplist 编码，后来统一到 quicklist），LPUSH/RPUSH 从两头塞，LPOP/RPOP 从两头取，天然是队列和栈的原材料。

我实际用得最多的是工作队列：LPUSH 任务，BRPOP 消费。BRPOP 是阻塞操作，没数据时消费者会挂起等待，而不是在应用层写空转循环，这对Worker 类程序特别友好。一个 key 被多个消费者 BRPOP，每条消息只会被一个消费者拿走，天然做了负载均衡。

但是很多人把 List 错用在"最新列表"场景，比如用户动态、评论流，用 LPUSH 往里塞，然后 LRANGE 0 9 取第一页。数据量小的时候没问题，量大之后翻页就变得很难受：LRANGE 的实现是遍历链表找起点位置，链表越长，定位越慢，复杂度是 O(N)。你只是在取第一页，Redis 却要数整整一串节点。这种场景的正解是 ZSet，按时间戳排序，直接 range by score，性能稳定。

另一个容易被忽略的是：List 的 LINSERT 和 LREM 都是 O(N) 操作，N 是列表长度。拿 List 当"有序集合"用，频繁在中间插入删除，性能会肉眼可见地变差。List 只适合"只从两端读写"的场景，一旦你想在中间做文章，大概率应该换类型。

还有一点，List 做消息队列有个天然短板：LPUSH 成功不代表消费者一定能处理，如果消费者在 BRPOP 拿到消息之后崩溃了，消息就丢了，没有确认机制。这也是后来 Stream 类型出现的原因之一。小项目临时用 List 没问题，但你要知道它的可靠性边界在哪里。

2.4 Set：去重之外的玩法

Set 的逻辑模型是"无序、不重复的集合"，核心命令 SADD/SISMEMBER/SPOP，以及对多个 Set 做交集 SINTER、并集 SUNION、差集 SDIFF。我整理过三类务实用法：

• 去重场景：一个用户点赞过的文章 ID，一个用户参与过的活动 ID，用 SADD 塞进去，重复添加自动忽略，查询用 SISMEMBER O(1)。
• 集合运算：比如"我关注的人"和"你关注的人"求共同关注，两个 Set 的 SINTER 一次搞定。朋友圈做"好友共同群聊"也可以这么算。
• 抽奖/随机剔除：SRANDMEMBER 做不删除的随机抽样，SPOP 做一次性随机取出，活动抽奖、随机推荐都方便。

Set 的坑主要在两处：

一是大集合的交集运算非常贵。SINTER 的复杂度是 O(N*M)，两个几十万成员的 Set 求交集，Redis 要遍历较小集合的每个元素去另一个集合里查存在性，可能卡住单线程几百毫秒。能提前算好结果缓存，就不要在请求路径上实时算。

二是内存开销偏高。Set 的每个成员既是集合元素，又要放在哈希表或跳表里保存元数据。如果你只是想知道"去重后有多少个"，完全不需要 Set，应该用 HyperLogLog，那个后面单独说。

Set 还有一个版本差异要注意：老版本 SADD 返回新增元素数量，可以用来判断是否已存在；现在 SADD 语义没变，但如果某个元素已存在，返回 0。有些代码在元素重复时依赖返回值做短路，没问题，但别把"返回值是不是 1"当成元素是否被成功加入的唯一判断，要考虑批量添加时部分已存在的情况。

2.5 ZSet：排序场景的核心利器

ZSet 是五种类型里信息量最大的一个：每个成员关联一个 double 类型的 score，内部用跳表 + 哈希表实现，读写路径上既能按 score 排序，又能 O(1) 查成员的 score。

我用得最多的场景是排行榜。游戏积分榜、内容热度榜，ZINCRBY 增加分数，ZREVRANGE 倒序取 Top N，几乎是一套标准答案。不需要自己维护排序，Redis 全帮你做了，而且性能稳定。

第二个我很看好的场景是延迟队列。把任务的执行时间戳作为 score，成员是任务 ID。要取出到期的任务时，ZRANGEBYSCORE 查 score 小于等于当前时间戳的所有成员，处理完 ZREM 删除。以前用 List 做延迟队列，要在消费端 sleep 轮询，或者用多个 List 按时间分桶，写起来非常别扭。用 ZSet 之后逻辑清晰很多，当然如果你对可靠性要求极高，Stream 有更完整的机制，但"至少能即刻执行，损失可接受"这种业务，ZSet 完全够用。

第三个常见的场景是分页取有序数据：ZREVRANGE key start stop 可以实现高性能分页，定位第 N 页时跳表会直接跳过前 N 个节点，不需要像 List 那样逐节点找。评论流、商品列表这类需求就适合。

ZSet 真正的坑是 score 精度。score 是 double，在业务里如果把时间戳毫秒级转成浮点数，不会有问题；但如果你把两个业务含义塞进一个 score，比如"用 score = 时间戳 * 10000 + 额外标记"，整数部分一旦超过 2^53，浮点精度就会丢。我自己遇到过用时间戳 + 随机数拼接 score 导致排序错乱的情况，后来强制改成两个字段：score 只用正常浮点，额外排序条件单独放成员名里做规则映射。

另外 ZRANGEBYSCORE 的区间边界默认是闭区间，如果要避开边界混入，需要自己协调开闭区间写法。项目越大，越要在一开始就约定好 score 的语义和精度约定。

3. 最容易搞混的两组类型辨析

3.1 想存对象：String JSON 还是 Hash

这是我在代码评审里经常和人争论的问题。初学者倾向 String JSON，理由很直接："我的对象本来就是一个 JSON，存起来省事。"有经验的开发者会先问一句：这个对象的字段会被单独读、单独改吗？改动频率高吗？

我给的判断标准是这样的：

如果对象是"一张订单快照"，下单之后没有人去改里面的某个字段，只看整体，用 String JSON 没问题，存进去和取出来都是完整的，语义清晰。如果对象是"商品库存、用户资料"这种会被高频局部更新的，选 Hash。还有个折中技巧：把整体快照存 String（比如详情页），但在需要频繁自增/改写的字段上用单独一个 Hash 或直接 String 计数器。不要怕多 key，Redis 的 key 本来就便宜，怕的是选错类型导致内存和 CPU 双高。

3.2 想存队列/消息流：List 还是 Stream

List 做消息队列的优势是极简：一个 key、两条命令、零配置。BRPOP 阻塞消费者，天然支持多消费者竞争消费。在小流量、可容忍少量丢消息的场景，它依然是性价比之王。

Stream 是 5.0 引入的类型，引入了消费组（Consumer Group）、消息 ID、ACK 确认和 pending 列表。它解决的是 List 做不到的几个问题：

• 消息被消费者读取后不自动消失，可以 ACK，也可以重新消费，实现了"至少一次"语义。
• 支持多个消费组各读各的，每个组内部维护自己的游标，适合"同一份数据喂给多个下游"的场景。
• XADD 自动生成单调递增的消息 ID，天然带时间信息。

我的建议是：只有"消息丢失会造成事故"并且"有多个消费者组"的需求，才值得引入 Stream。如果只是把任务分发给几个 Worker，List + BRPOP 就够了；如果对消息可靠性有强诉求，也可以用 Stream 的 XACK 机制做确认。很多团队一上来就 Stream，结果消费组里的 pending 列表堆积没人处理，XREADGROUP 的 block 参数调错，比 List 还容易出问题。类型越新，配套运维认知也要跟上，否则高级功能反而是负担。

3.3 去重和统计：Set、HyperLogLog、Bitmap 怎么选

这是我在技术分享里经常出的一道选择题。需求一句话："统计今天访问过页面的独立用户数，去重计数。"

• Set：每个用户 ID 一个成员，SADD 进去，SCARD 拿大小。准确、可反查、但是贵。一亿用户 -> 一亿个成员，内存按 GB 计算，如果你的 Redis 是备份在单机上，这笔内存成本会直接反映到账单上。
• HyperLogLog：固定约 12KB 内存，PFADD 一个用户，PFCOUNT 拿到估计值。标准误差 0.81% 左右，不能反查具体用户，只给你一个数字。适合海量 UV 统计这种不太较真、只需要量级的场景。
• Bitmap：假设用户 ID 是连续整数（或者映射到连续区间），位图长度 = 用户数上限，每一位 0/1 表示访问与否。空间极紧凑，还支持 BITOP 做多个位图的交并集，算忠实用户很优雅。但它强依赖 ID 的自增连续性，非连续 ID 用位图就是在浪费空间。

这个选择其实不是在比谁更牛，而是在比你的业务能不能接受近似值、空间预算有多少、是否要反查成员。把这三个问题回答了，类型基本就定了。Set 保守，HyperLogLog 经济，Bitmap 精准且便宜但有前提条件。

4. 进阶类型的实战选型：什么时候才是正确答案

4.1 Bitmap：签到、在线状态、活跃统计的极致压缩

Bitmap 在 Redis 里并没有独立的底层结构，它本质上是 String 类型上的位操作。SETBIT key offset value 和 GETBIT key offset，以及 BITCOUNT 统计为 1 的位数。

我最常用它在连续型布尔状态场景：

• 用户签到：key 是sign:202403，设备 ID 或自增用户 ID 做 offset，签到当天对应位设为 1，BITCOUNT 直接拿到本月签到了多少天。一天只占 1 bit。
• 每日活跃：用户 ID 做 offset，当天活跃的置 1，第二天新 key。一行 IO 就把 DAU 统计了，比 Set 省几十倍内存。
• 简单布隆替代：判断某个 ID 是否处理过，用一个足够大的位图做 hash 映射，空间可控，但要注意误判率，别在严格一致性场景里用。

Bitamp 的坑主要在两个方向：

一是偏移量语义很容易混乱。位偏移从 0 开始，key 的拆分要按时间窗口规划好，否则你要对"上个月第 31 天对应哪个位"做各种计算，代码可读性极差。建议在 key 里直接带上时间粒度，代码里封装一层偏移换算函数，别在业务代码里裸写 SETBIT。

二是BITCOUNT 与 SETBIT 高并发争抢同一个 key的性能。同一个位图 key 被多个进程频繁 SETBIT，其实 Redis 单线程会把这些操作串行化，不会数据错乱，但对同一个 key 的热点写也可能成为瓶颈。如果业务拆 key 的空间足够，优先按业务/用户段拆开。

4.2 HyperLogLog：千万级 UV 统计不是梦

HyperLogLog 的引入非常有意思：你只需要"大概的日活数字"来看趋势，不需要知道具体是哪几个用户，那 Set 的精确记录就成了纯浪费。HLL 用概率算法把内存压到 12KB 上下，代价是结果有 0.81% 的标准误差。

实际上我在做活动报表时经常这么用：每天的 PV 访问 key 都 PFADD 一次，月底把整个月的 daily key 全部 PFCOUNT，得到月活近似值。注意 HLL 在基数比较小的时候误差也很小，基数很大时误差也基本稳定在几个百分点内，所以"用它看量级不要看精确实数"就对了。

HLL 的边界也很清楚：

• 无法反查有哪些用户，只能回答"有多少个不同元素"。
• PFCOUNT 是只是统计数量，没有"某个用户是否已经计数过"的查询能力。
• 多个 HLL 可以用 PFMERGE 合并，这是月活场景的好帮手，但要小心合并后返回的是估计值，不是精确计数。

4.3 Geo：附近的人、门店距离计算的取舍

Redis 的 GEO 类型基于 GeoHash 把经纬度编码到 ZSet 里：成员的 score 是 52 位的 geohash，底层还是那个你熟悉的 ZSet。GEOADD 添加点，GEOSEARCH 按圆心或矩形范围搜，GEODIST 算距离，非常契合"附近 X 公里"这类 LBS 需求。

但它有明确的使用前提。第一，误差通常在几十米级别，如果业务要求米级精确，Redis GEO 不是最优选，可能需要引入专业的地理数据库。第二，你存的是"当前坐标"还是"历史轨迹"要想清楚。如果把用户每 10 秒上报的坐标都写进同一个 GEO key，很快就变成一个巨大的 ZSet，性能和内存都难看。通常只保留"用户最新位置"这一个数据点，历史轨迹交给时序库。

由于 GEO 底层是 ZSet，ZREM 可以直接删除某个点。但注意 ZSCORE 拿到的分数是 geohash 编码，不是距离，也没有直接的单位换算意义。我见过有人试图拿 score 当距离做排序，结果排序完全乱掉，因为 geohash 的分段编码在二维空间上根本不保证一维单调性。

4.4 Stream：从消息队列到事件流

Stream 是 Redis 5.0 之后面向消息流场景推出的类型，功能集是完整的：XADD 追加消息，XREAD 按 ID 增量读，XREADGROUP 配合消费组做多消费者，XACK 确认消费，还有 XAUTOCLAIM 处理 pending 超时。它的存在解决的正是 List 做队列时缺的那块"可靠性拼图"。

我实践中觉得最值得用 Stream 的场景是：同一份订单事件要被多个下游消费，每个下游有独立进度。比如订单创建后，需要同时触发积分、短信、库存三个服务，而且三个服务互相不能影响同一条消息的处理进度。用 List 根本做不到"三条消费者链各自维护游标"，Stream 的消费组就是为这个设计的。

不过 Stream 复杂度不低，容易踩的坑也多：

• 消息无限堆积会让内存爆炸。XADD 默认不限制长度，生产环境必须配 MAXLEN 或者定期 XTRIM；如果用MAXLEN ~ 1000，近似裁剪能明显降低阻塞概率，业务里习惯加~是好习惯。
• pending 列表需要监控。消费者拿到消息但没 XACK，消息会一直停留在 pending 里；XAUTOCLAIM 可以捞回超时消息，但要记得更新消费者的实际状态。
• 消费组的block参数是毫秒，很多人按秒填，导致消费者提前返回，然后又写空转循环，白白增加命令量。

我个人的判断线：只要业务需要"多个独立消费方"或"消息必须能重新消费"，就用 Stream；如果只是单队列分给多个 Worker，List + BRPOP 或 Stream 的>读取就够了。

5. 内存与性能的底层细节：为什么你的 Redis 内存账单总是偏高

5.1 底层编码：从 intset、ziplist 到 listpack、quicklist 的变化

Redis 为了让小数据更省内存，同一种数据类型在不同数据规模下会切换底层结构。这条链路在面试里常被问到，但在线上排障时更关键：**你以为是类型浪费了内存，其实可能是编码没有生效或触发了转换。

历史上有几个标志性编码：

• intset：Set 在元素全部是整数且数量少时使用，它是有序整数数组，内存极紧凑，查找用二分。但如果插入一个非整数成员，intset 会升级成 hashtable，这是不可逆的，所以要小心在 intset 编码的 Set 里混入字符串。
• ziplist：早期 Hash、List、ZSet 在元素数量少、单个元素体积小时用，本质是紧凑数组，每个节点带前驱长度信息，便于双向遍历。ziplist 有连锁更新问题，就是某个节点长度变化引发后续节点的 prevlen 需要扩张，最坏情况是 O(N)，所以它后来被 listpack 取代。
• listpack：从 Redis 7.0 起主导的紧凑编码，设计上避免了连锁更新，成为小集合的默认方案。
• quicklist：List 的专用编码，本质是"多个 ziplist/listpack 节点串成的链表"，既保证两端操作快，又保证中间节点紧凑，还控制单节点过大。
• skiplist + dict：ZSet 在数据量大时的正式结构，跳表负责按 score 排序，dict 负责按 member O(1) 查 score。

有意思的是，String 也有三种编码：int 存整数、embstr 存短字符串（Redis 中 44 字节以下直接分配连续内存）、raw 存长字符串。从 39 字节到 44 字节的阈值变化是 SDS 头大小调整带来的，每次选型时没必要死记，但知道有这个阈值就能解释为什么短 key 和短 value 省出来的内存非常可观。

5.2 什么时候会触发编码转换

每个类型的转换阈值都可以在 redis.conf 里配置，不过名字和默认值随版本变过不少。拿 7.x 举例，相关配置大概是：

在 7.0 之前这些参数前缀是ziplist，升级配置时要留意。实际项目里，编码转换不是按配置即刻生效，而是插入新数据时重新评估。也就是说，一个 Hash 已经达到 128 个 field，hsets 第 129 个 field 的瞬间整个 Hash 会从 listpack 变成 hashtable，内存和读写路径都会变化，这个瞬时性能抖动在高峰期有可能被监控捕捉到。

反面例子我也踩过：一个直播弹幕场景用 ZSet，成员 ID 是 20 字节左右的字符串，一开始成员只有 50 个，listpack 编码跑得很好。某天活动突然爆量，成员数冲过 128，编码切到 skiplist + dict，同一个 ZADD 命令的耗时从零点几毫秒涨到一两毫秒，虽然没有造成事故，但监控曲线一下就变了。记住：小规模数据的性能不能直接推导到大规模之后，编码切换就是那堵墙。

下面给一个大家关心的问题做表格总结：

5.3 大 key 问题：类型不同，风险不同

大 key 没有绝对定义，业界一般把"单个 key 的 value 超过 10KB"或"集合类型成员数超过 5000"作为关注线。核心风险是阻塞 Redis 单线程：String 大 value 的 GET 会把一大块内存通过网络传输出去，集合类型的全量操作比如 HGETALL、SMEMBERS、ZRANGEALL 会在服务端遍历所有元素，期间整个 Redis 实例都无法响应其他命令。

我有一次真实的教训：某个 Hash 在业务迭代中 field 数涨到了几十万，代码里有个定时任务每天用 HGETALL 拉全量做数据对账，直接导致对账期间 Redis 的主线程卡了十几秒，线上接口大面积超时。后来改成 HSCAN 分批拉取，加上对账的任务只调度一次，才算解决。

排查大 key 的手段其实很标准：

• redis-cli --bigkeys是快速扫描工具，逐类型统计最大成员数和最大字节数。
• MEMORY USAGE key精准看某个 key 的内存占用。
• DEBUG OBJECT key可以查看编码和序列化长度，但不能随便在生产环境用太多，因为调试命令本身有开销。

清理大 key 也有讲究：DEL 一个几十万成员的 Hash，删除操作本身要遍历所有节点，会造成阻塞。Redis 从 4.0 开始支持UNLINK，异步释放 key，不会阻塞主线程，这是清理大 key 的首选。不过 UNLINK 只是把释放放到后台线程，内存的回收速度依然受物理资源影响，别指望删除一个 5GB 的 key 内存立刻回到可用状态。

6. 实操踩坑清单与我的个人检查表

6.1 常见误区的快速排查

我在团队里做过几次 Redis 使用规范评审，每次都能看到类似的错误，这里列出来供你对照：

每个坑背后，本质都是"数据结构的内存模型和时间复杂度模型"没有提前想清楚。与其等事故出来再复盘，不如在建表阶段就做一次数据建模。

6.2 我的个人数据建模检查表

当我在一个需求里准备用 Redis 时，会按下面几步过一遍，你也可以直接抄走：

1. 先写 key 设计表：业务前缀:对象标识:时间维度，明确 key 的 TTL。
2. 选类型时问自己三个问题：单值还是多属性？字段级更新是否频繁？需不需要排序/去重/统计？
3. 做内存估算：预估数据量 * 单条字节数，加上编码开向量级，先用MEMORY USAGE在测试环境实测一个 key，再乘总量。
4. 压测边界：用测试脚本往目标类型里插入数据，观察编码转换点前后的延迟和内存变化，确认阈值配置和业务量匹配。
5. 写清除策略：大 key 用什么方式清理，集合类型的全量操作是否在请求路径上，定时任务是否会造成阻塞。
6. 加监控：至少看INFO memory的 used_memory、redis-cli --bigkeys的定期报告，以及慢查询日志里有没有类型相关的长命令。

这套流程不复杂，但确实能救回很多线上事故。尤其是"先估算再动手"这一条，懒不得。一个 Hash 和一个 String JSON 在单条数据上的差别可能只有几百字节，但乘上千万级数据量，差异就变成了几个 GB 的内存和一台物理机。

6.3 几个让我印象深刻的类型切换案例

最后讲两个从错误类型转正确类型的案例，权当参考。

第一个是用户收藏夹：原本用 Set 存收藏的文章 ID，后续需求要展示"最近收藏的 10 篇文章"，Set 根本没法排序，只能在业务代码里把成员全部取出来再做时间排序。后来改成 ZSet，把收藏时间戳作为 score，最新收藏直接 ZREVRANGE 0 9，代码量减少一大截，对账逻辑也更清晰。

第二个是商品详情的热点字段统计：最开始的方案是每次点击都 LPUSH 一个商品 ID 到 List，再用 LLEN 看热度。这个方案有个明显问题：List 里会有大量重复商品 ID，内存浪费严重，而且 LLEN 只看总量，看不到去重后的热度。改成 ZSet 之后，同一商品 ID 只保存一条记录，ZINCRBY 每次点击分数 +1，ZREVRANGE 拿的就是真实热度排名，内存节省了不止一半。

这两个例子的共同点是：不是 Redis 不够快，而是用错了结构，每次都要在业务层做额外的数据处理。选对类型，很多"看起来需要 Redis 之外手段才能做"的需求，命令本身就替你完成了。

我在实际使用里的最后一条心得：数据的组织方式变了，代码的逻辑和价值都会跟着变。别急着写代码，先把这张类型选型表在心里过一遍，起码能帮你在未来的很多个晚上睡个好觉。