企业官网建设流程全解析

三年前接手一个项目，翻它的Redis使用记录时我愣了一下：整个实例只有一种数据结构，全是String。购物车是JSON串、排行榜是JSON串、用户会话还是JSON串。改购物车里的一个商品数量，要把整条JSON反序列化出来、改完再整体写回。那个实例内存吃到18GB，我粗算了一下有效数据不到4GB。后来把Hash、ZSet这些类型真正用起来，同一套业务压到了6GB以内，接口平均耗时还降了三成。

这件事让我意识到，Redis的数据类型不是"入门第一课"那种学完就扔的知识点，它直接决定了你的内存账、延迟曲线和后续扩容节奏。很多人对Redis数据类型的理解停留在"String存字符串、List存列表、Set去重"这一层，能跑通业务就收手了，至于每种类型在什么数据规模下会换底层编码、换编码之后内存翻几倍、哪些命令在大集合上会拖住整个实例，一概不清楚。等到线上出现毛刺、内存告警、慢查询堆积，才开始回头补这一课，代价往往不小。

这篇内容就是想把"数据类型"和"使用场景"这两件事绑在一起讲透。不是罗列API，而是从访问模式倒推选型，从底层编码解释内存差异，从真实排查链路还原踩坑现场。适合已经能写增删改查、但还没系统梳理过选型逻辑的后端同学，也适合正在做缓存改造、需要给团队定规范的人。文中涉及的具体数值和阈值以常见版本为参照，不同版本默认配置会有差异，落地前建议用CONFIG GET核一遍。

1. 五种基础类型的真实边界：能存什么只是表象

大部分人学Redis类型时记住的是"String、Hash、List、Set、ZSet"这五个名字，但真正决定你用得对不对的，是每种类型在什么条件下会切换内部编码。同一个Hash，字段少的时候是一块连续内存，字段多了会变成哈希表，内存占用和访问特性完全不同。不理解这一层，你写的代码在小数据量下飞快，数据一涨就开始莫名其妙地抖。

1.1 String：被当成万能容器之后的隐性成本

String是唯一一个能和几乎所有业务对上号的类型，计数器、会话、配置、序列化对象，什么都能往里塞。它的上限是512MB，这个数字很容易让人产生"够用了"的错觉。但String的编码分三种：能解析成整数的走int编码，短字符串（44字节以内）走embstr，超过就变成raw。embstr和raw的差别在于内存分配次数——embstr把redisObject和SDS一次性分配，raw要分两次，释放的时候也一样。单条数据看不出差别，几十万条累积起来就是可观的内存碎片。

更值得说的是整数共享对象。0到9999这个区间的整数，Redis会复用同一批对象，不额外分配内存。所以用String做计数器时，如果你的计数长期落在这个区间，内存开销几乎可以忽略；一旦超过，每条就是一个独立对象。这个细节在做海量小计数（比如每篇文章的阅读数）时会体现得很明显。

# 看编码，别靠猜 OBJECT ENCODING user:1001:session # 看单key实际占用 MEMORY USAGE user:1001:session SAMPLES 0

我见过最常见的误用是把整个对象序列化成JSON塞进String，然后每次读出来改一个字段再写回去。这种写法在并发下是有竞态的，两个请求同时读取、各自修改、各自写回，后写的会覆盖先写的。想靠WATCH做乐观锁，又容易在高并发下频繁失败重试。这种场景换成Hash，用HSET只更新变动字段，问题就消失了。

1.2 Hash：字段数与值长度共同决定的内存拐点

Hash是"小对象聚合"的天然容器，用户信息、商品属性、配置项都适合。它在字段少且值短的时候用listpack（早期版本是ziplist）存储，本质是一块连续内存，省掉了哈希表的指针开销。触发转换的条件由两个参数控制：hash-max-listpack-entries默认128，hash-max-listpack-value默认64。字段数超过128，或者任意一个字段的值超过64字节，整个Hash就会转成hashtable。

转换是单向的，转过去就回不来了。这个特性很关键：一个原本只有十几个字段的Hash，某天业务加了一个长文本字段（比如商品详情描述），整个Hash立刻变成hashtable，内存可能翻两三倍。我自己就遇到过这种情况，一个存商品基础信息的Hash加了"卖点文案"字段之后，那个实例的内存曲线肉眼可见地抬了一截。

所以定规范的时候，我会明确一条：Hash只放短字段，长文本单独用String存，key按biz:id:field命名。这样既不破坏Hash的紧凑编码，也方便单独设置过期时间。

1.3 List：双端队列好用，但别拿它当"数组"

List的定位是双端链表，从左或从右压入弹出都是O(1)，适合做队列、栈、最新N条动态。它在元素少的时候也是listpack编码，list-max-listpack-size默认128（正数表示元素个数上限，负数表示按字节数限制，比如-2代表8KB）。元素多了或者单个元素太大，就转成quicklist。

List最容易被误用的地方是把它当数组用，靠LINDEX随机访问中间元素。这是O(N)操作，列表一长就慢。还有人用LRANGE key 0 -1取全量数据，几万个元素一次性拉回应用层，网络和序列化开销都很吓人，而且这条命令执行期间会占住主线程。

真正适合List的场景是"只需要两端"的操作：消息队列、最新评论列表、操作日志。做队列时用LPUSH进、BRPOP出，配上阻塞超时，比轮询优雅得多。但这里有个隐蔽的坑，后文会专门讲——BRPOP弹出即删除，消费者拿到消息后如果进程崩了，这条消息就永久丢了。

# 生产者 LPUSH queue:order '{"orderId":"A1001","ts":1710000000}' # 消费者，阻塞5秒 BRPOP queue:order 5

1.4 Set与ZSet：去重和排序是两个独立需求

Set解决的是"是否存在"和"集合运算"，ZSet解决的是"按分数排序"。这两个经常被混着用，比如明明只需要去重，却上了ZSet，白白多存一份score；或者明明需要排序，却用Set存了再在应用层排，白白浪费一次全量传输。

Set在元素全是整数且数量不超过set-max-intset-entries（默认512）时用intset编码，内存极其紧凑，而且是有序数组，查找用二分。一旦混入非整数元素，立刻转hashtable，内存涨得很明显。这个特性可以利用：如果你的集合本来就是纯数字ID，尽量别往里塞字符串标签，保持intset编码能省下大量内存。

ZSet的底层是跳表加哈希表（元素少时是listpack），所以它既能O(1)查分数，又能O(log N)按分数范围取。zset-max-listpack-entries默认128，zset-max-listpack-value默认64。做排行榜时，ZSet是标准答案，ZINCRBY加分、ZREVRANGE取前N、ZRANK查名次，一条龙。

Set的集合运算能力经常被低估。共同关注用SINTER，可能认识的人用SDIFF，标签筛选用SUNIONSTORE把结果落盘再做分页。这类运算在数据量不大时非常划算，因为计算发生在Redis内部，省掉了把集合拉到应用层的内存和网络开销。

2. 从访问模式倒推选型：三个提问定类型

选型这件事，与其背"什么场景用什么类型"，不如养成一个习惯：拿到需求先问三个问题。这三个问题答完，类型基本就定了，剩下的只是参数调优。

2.1 第一问：你要的是整体还是部分

如果每次读写都是整个对象一起进出，那String序列化就够了，简单直接。如果经常只改其中一两个字段，Hash更合适，因为它支持字段级原子更新，也不用担心并发覆盖。如果只关心某个对象的一个数值变化（比如库存减一），那就用String加DECRBY，别为了"结构清晰"绕一圈。

这一问其实是在判断读写粒度。粒度粗、整体性强的场景，越简单的结构越好；粒度细、字段独立的场景，聚合类型才有价值。我见过把配置项拆成几十个独立key的，取一次配置要发几十次请求，这就是粒度拆过头了，反而该用Hash聚合。

2.2 第二问：数据量级和单条大小是多少

量级决定了你要不要担心编码转换。字段数低于128、值长度低于64的Hash是紧凑的，一旦越界就换编码。元素数量低于512的整数Set是intset，混入一个字符串就变hashtable。这些阈值不是玄学，是内存账的分水岭。

预估量级时不要只看当前。一个"现在只有几十个字段"的配置Hash，如果业务规划里要支持商家自定义字段，那迟早会突破128。与其等到线上转换，不如一开始就把长尾字段拆出去。

2.3 第三问：需不需要范围查询或排序

只要出现"前N名""某时间段内""分数区间"这类词，基本就锁定ZSet了。ZSet的ZRANGEBYSCORE能高效做范围扫描，配合LIMIT做分页。如果只是判断存在性，用Set甚至Bitmap更省。如果需要按插入顺序取最新N条，List的LPUSH加LTRIM组合比ZSet更轻。

把这三问串起来看，很多纠结就消失了。比如"用户签到记录"这个需求，如果只判断今天签没签、本月签了几天，Bitmap是最优解，一天一位，一个月31位，一年365位，一个用户一年才46字节。但如果还要查"最近七天连续签到"，Bitmap就得多次GETBIT，不如用一个Hash存日期到状态的映射，或者干脆用Set存已签到日期。

3. 四种冷门类型的救场时刻

前面五种是主力，剩下四种在特定场景下能起到"别人写几百行你写三行"的效果。它们的共同点是：用极小的内存代价换取特定的计算能力，代价是能力有边界，越界就失真。

3.1 Bitmap：签到与活跃统计的极致压缩

Bitmap本质是String的位操作，SETBIT、GETBIT、BITCOUNT。它能表达"某个ID在某个位置是否为1"，最典型的就是用户签到：key是sign:userId:202403，偏移量是日期减一，签到了就SETBIT key 4 1。统计本月签到天数直接BITCOUNT，一次O(N)但N是字节数，一个月才4个字节。

单个Bitmap的最大偏移是2^32-1，也就是512MB。这个上限意味着它适合"稠密"的ID空间，比如用户ID连续且总量可控。如果用户ID是雪花算法生成的19位长整数，直接拿ID当偏移量，会瞬间撑爆内存。正确做法是做一层映射，或者改用Set。

还有一点要注意，BITCOUNT统计的是整个key，如果key里混了多个维度（比如签到和活跃共用），结果就串了。我一般会给每个用途单独开key，命名上带业务前缀。

# 3月5日签到（偏移从0开始） SETBIT sign:u1001:202403 4 1 # 统计3月签到天数 BITCOUNT sign:u1001:202403 # 判断今天是否已签 GETBIT sign:u1001:202403 4

稀疏场景是Bitmap的软肋。一万个用户里只有十个活跃，你还得为最大ID分配位图空间。这种时候要么改用Set，要么用分片Bitmap，按ID区间拆成多个key，避免单个key过大。

3.2 HyperLogLog：UV统计的误差换内存

统计独立访客是个经典难题，用Set精确去重，一千万UV就是几百MB；用HyperLogLog，固定12KB，标准误差0.81%。这个交换在绝大多数业务场景下是划算的，因为UV数字本身带个百分之一的误差，运营同学根本感知不到。

用法极简：PFADD uv:20240305 user1 user2，PFCOUNT uv:20240305拿估算值，PFMERGE做多天合并。它支持合并这一点很关键，意味着你可以按天存，月末合并出月活，不用维护一个越来越大的总key。

需要提醒的是HyperLogLog不精确，也不能取出元素。任何需要"知道具体是谁"的场景都不能用它。另外它的计数在数据量很小时是精确的（底层稀疏编码），超过一定阈值才转密集编码开始有误差，所以小流量下你可以放心用。

3.3 GEO：地理位置查询的顺手方案

GEO是ZSet的封装，底层用geohash把二维坐标编码成一维分数，所以它天然支持按分数范围查询。GEOADD存点，GEOSEARCH按圆心半径或者矩形范围查，GEODIST算两点距离。做"附近的门店""周边的骑手"这类需求，几行命令就能跑通，不用引入专门的地理索引服务。

精度上，Redis的GEO用52位geohash，误差在0.6米左右，对于"附近500米"这种需求完全够用。但要注意它的查询是二维矩形近似，GEOSEARCH的BYRADIUS会先算出外包矩形再过滤，边界上偶尔会多返回几个点，应用层做一次精确距离过滤即可。

删除GEO里的点用ZREM，因为它本质就是ZSet。这个细节很多人不知道，到处找GEODEL，其实根本不存在。

3.4 Stream：轻量消息队列与消费组

Stream是Redis 5.0引入的，定位是"能持久化、支持消费组、能重投"的消息结构。XADD追加消息，XREADGROUP按消费组读取，XACK确认，XPENDING查未确认的，XAUTOCLAIM接管超时未确认的消息。这一套下来，一个轻量级可靠队列就有了。

它适合什么场景？消息量不大、不想为此单独维护一套消息中间件、又需要基本的确认重投能力。比如站内通知、异步任务分发。不适合什么场景？超大规模吞吐、需要严格顺序、需要跨机房复制，这些还是得用专业队列。

一个实操细节是XADD时尽量显式指定MAXLEN做裁剪，比如XADD stream:notify MAXLEN ~ 10000 * ...，用~是近似裁剪，性能更好。不裁剪的话Stream会无限增长，内存迟早告警。

# 建消费组，从最新消息开始 XGROUP CREATE stream:notify group:mail $ MKSTREAM # 消费 XREADGROUP GROUP group:mail consumer:1 COUNT 10 BLOCK 5000 STREAMS stream:notify > # 处理成功后确认 XACK stream:notify group:mail 1710000000000-0

4. 底层编码与内存：同样的数据为什么别人省一半

线上内存告警的时候，最常见的解释是"数据量涨了"，但实际情况往往是编码退化。同一批数据，编码选对了占100MB，选错了占300MB，业务代码一行没改。

4.1 编码转换的触发条件要背下来

这些值都能通过CONFIG GET查到，也能改。改之前想清楚：调大阈值意味着更多数据走紧凑编码，省内存但单次操作可能变慢（因为listpack是线性扫描）；调小则相反。我的经验是默认值对大多数业务是合理的，除非你明确知道自己的数据形态，否则别乱动。

一个高频误区是以为Hash的字段值可以随便长。实际上只要有一个字段超过64字节，整个Hash就转hashtable。一个存用户信息的Hash，如果塞了个头像URL（经常超过64字节），转换就发生了。解决办法是把这类长字段拆成独立key。

4.2 大key识别：先量出来再谈优化

大key没有绝对定义，通常按"value超过1MB"或"集合元素超过5000"作为经验线。它的危害不在于占内存，而在于操作它的时候会长时间占用主线程。删除一个百万元素的Set，如果直接用DEL，主线程会卡住；用UNLINK则是异步回收，把释放动作放到后台线程。

识别手段有几个：redis-cli --bigkeys扫一遍能给出每种类型的最大key；MEMORY USAGE key看单个key的实际占用；慢查询日志里那些HGETALL、SMEMBERS、LRANGE 0 -1往往就是大key在作祟。

# 扫描大key，注意别在高峰期跑 redis-cli -h 127.0.0.1 -p 6379 --bigkeys # 单key内存核算 redis-cli MEMORY USAGE user:1001:profile SAMPLES 0

--bigkeys内部用的是SCAN，不会阻塞，但会消耗CPU，业务高峰期跑还是会影响。更稳妥的做法是从慢日志和监控里的key大小分布入手，定位到具体业务再针对性排查。

4.3 过期策略和类型选择的联动

给key设过期时间几乎是标配，但不同类型的过期行为有差别。Redis采用惰性删除加定期删除，过期key不是到点立刻消失，而是在被访问时或者定期任务扫到时才清理。这意味着一个大Hash即使设了TTL，到期后如果一直没被访问，内存也不会马上释放。

更麻烦的是大key过期。一个几十万元素的ZSet到期被删，如果正好赶上定期删除任务扫到它，那一下的释放开销是实打实的。所以对超大集合，我倾向于拆分成多个小key，或者用UNLINK主动删。

另外集群模式下，多key操作必须在同一个slot。做集合运算SINTER、批量MGET时，如果key分散在不同节点会直接报错。解决办法是用hash tag，比如{user:1001}:tags和{user:1001}:follows，大括号里的内容相同就会落到同一个slot。

5. 三个真实坑的完整排查链路

讲原理容易，出问题的时候能不能顺着现象摸到根因，才是分水岭。下面三个坑都是我在实际项目里遇到并跟完整个排查过程的，写出来供参考。

5.1 排行榜深分页：从接口变慢到方案重构

现象是排行榜接口的P99从30ms涨到了400ms，而且随着榜单数据增长持续恶化。第一反应是网络或者数据库，但看了链路追踪发现时间全耗在Redis那一步。

先看慢查询日志，SLOWLOG GET 20里没有明显记录，说明单条命令不慢。再看监控，那个ZSet的ZCARD是80多万。接着我去看代码，发现问题出在业务侧：为了返回"总页数"，每次请求都调一次ZCARD，然后前端传页码，后端用ZRANGE key start stop WITHSCORES取当前页。这个写法本身复杂度不高，但场景里还有个隐藏动作——为了过滤掉已下架商品，代码先把整个榜单ZRANGE key 0 -1拉回应用层过滤，再分页。

80万个元素带着score拉回来，光反序列化就得几百毫秒。这就是根因。修复方案分两步：一是把过滤前置，下架时直接从ZSet里ZREM，保证榜单里全是有效数据；二是分页改成游标式，用上一页最后一个元素的score作为下一页起点，ZRANGEBYSCORE key (lastScore +inf LIMIT 0 20，彻底摆脱页码。

改完之后P99回到35ms左右，而且不随数据量增长而恶化。这里的心得是：任何"先把全量取回来再处理"的写法，在小数据量下都不会暴露问题，它是典型的规模敏感型缺陷。

5.2 Hash字段暴涨导致的延迟毛刺

监控上出现规律性的延迟毛刺，每隔几分钟就有一次几十毫秒的尖峰。Redis本身CPU不高，内存也平稳，就是偶发慢。

排查思路是先确认是不是持久化导致的。看了LATENCY HISTORY，发现有fork相关的记录，但时间点和毛刺不完全吻合。又看了INFO commandstats，发现HGETALL的调用次数不高但平均耗时异常，usec_per_call比正常高一个数量级。

顺着HGETALL去找调用方，定位到一个商品详情接口。那个Hash叫product:meta:{id}，原本设计只存十几个短字段，后来运营侧加了个"规格参数"，把所有SKU的规格都塞进去了，字段数涨到几百，单个值也有长有短。字段一多，Hash从listpack转成hashtable，HGETALL要遍历整个哈希表并构造返回，遇到大Hash时这一次调用就能占住主线程十几毫秒。

修复分两块：短期把HGETALL换成HMGET，只取页面真正需要的字段；长期把规格参数拆成独立key，按需加载。改完毛刺消失。这件事让我在后来的规范里加了一条硬约束：禁止对大Hash使用HGETALL，需要遍历一律用HSCAN分批。

5.3 List当队列用，消息静默丢失

这个坑最隐蔽。现象是偶尔有订单状态没有推进，查日志发现对应的异步任务压根没执行，但生产端明明LPUSH成功了。

代码是这样写的：消费者用BRPOP queue:task 5拿任务，拿到之后执行业务逻辑。问题就在这里——BRPOP是弹出即删除，消息一离开Redis就不存在了。如果消费者拿到消息后进程被重启、或者执行中间抛了未捕获异常，这条消息就凭空消失了，没有任何痕迹。

修复用可靠队列的模式：BRPOPLPUSH（新版本用LMOVE source destination RIGHT LEFT）把消息从待处理队列原子地移到"处理中"队列，业务执行成功后再从处理中队列删掉。这样即使消费者崩溃，消息还留在处理中队列里，可以靠一个补偿任务扫描超时未确认的消息重新入队。

# 原子地从待处理队列取出并放入处理中队列 LMOVE queue:task queue:task:processing RIGHT LEFT # 业务成功后删除 LREM queue:task:processing 0 '<payload>'

补偿任务扫描queue:task:processing里停留超过阈值（比如5分钟）的消息，重新LMOVE回主队列。这个模式的代价是要多维护一个队列和一个定时任务，但换来的是"消息不丢"这个底线保证。

后来我复盘，这个问题的本质是把Redis当成了可靠消息中间件。Redis的List队列提供的是"至少一次"投递的基础设施，但需要你自己实现确认和重投。如果业务对消息可靠性要求高、又不想自己写这套逻辑，Stream的消费组是更省事的选择，XACK和XPENDING已经把确认机制内置了。

6. 落地时我会检查的几件事

写规范容易，让规范落地难。这几年我给几个团队做过缓存层梳理，最后沉淀下来的checklist其实不长，但每一条都是踩过坑之后加的。

第一件是key的命名和过期策略。命名必须能看出业务域和类型，比如cart:{uid}、rank:hot:202403。所有缓存key必须设TTL，除非有明确的持久化理由。没有TTL的key是内存泄漏的温床，我见过一个项目里三千多万个key没有过期时间，来源早就没人记得了。

第二件是禁止在生产环境用KEYS。这个命令会遍历整个键空间，几百万key的实例上执行一次能卡住好几秒。统一改用SCAN游标遍历，虽然它不保证一次性返回全量，但不会阻塞。

第三件是集合类操作必须评估元素规模。SMEMBERS、HGETALL、LRANGE 0 -1这三个命令在大集合上都是灾难，代码评审时看到就该拦下来。需要全量数据时用SSCAN、HSCAN分批。

第四件是大key的删除走UNLINK。DEL是同步释放，大key会阻塞主线程；UNLINK把释放挪到后台线程，主线程只做逻辑删除。

第五件是集群模式下的多key操作要检查slot。凡是MGET、SINTER、SUNION这类命令，涉及的key必须落在同一个slot，否则直接报CROSSSLOT错误。用hash tag是最省事的办法。

还有一个容易被忽略的点：pipeline和事务的边界。pipeline只是把多条命令打包发送，减少RTT，它不保证原子性；MULTI/EXEC保证原子但不保证全部成功，执行过程中某条命令失败，其余命令照样执行。真正需要"要么全成功"的语义，得靠Lua脚本。这一点在做库存扣减、积分变更这类操作时尤其重要。

最后分享一个我个人的习惯：接手任何用到Redis的项目，第一件事是跑一遍--bigkeys和看一遍慢查询日志，再CONFIG GET maxmemory-policy确认淘汰策略。这三步下来，基本能判断出这个实例的健康度和团队的使用水平。淘汰策略如果是noeviction而内存又设了上限，那写满之后所有写操作都会报错，这种配置在缓存场景里几乎一定是错的，应该用allkeys-lru或volatile-lru。

数据类型的选型没有标准答案，只有"在当前数据规模、访问模式和可靠性要求下最不坏的那个"。我自己的判断顺序是：先看读写粒度定基础类型，再看量级估编码转换风险，最后看可靠性要求决定要不要上Stream或者自己补确认机制。这套顺序用熟了，大部分选型纠结在动手之前就能消解掉。