Redis数据类型选型与底层编码：从访问模式到内存优化实战

三年前接手一个项目翻它的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默认128hash-max-listpack-value默认64。字段数超过128或者任意一个字段的值超过64字节整个Hash就会转成hashtable。转换是单向的转过去就回不来了。这个特性很关键一个原本只有十几个字段的Hash某天业务加了一个长文本字段比如商品详情描述整个Hash立刻变成hashtable内存可能翻两三倍。我自己就遇到过这种情况一个存商品基础信息的Hash加了卖点文案字段之后那个实例的内存曲线肉眼可见地抬了一截。所以定规范的时候我会明确一条Hash只放短字段长文本单独用String存key按biz:id:field命名。这样既不破坏Hash的紧凑编码也方便单独设置过期时间。场景推荐做法原因用户基础信息十几个短字段Hashlistpack编码内存紧凑商品详情长文案独立String避免撑破Hash的value阈值需要整体过期的对象整体存String或Hash设TTL字段级过期不支持需要按字段递增Hash的HINCRBY原子操作无需读改写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 51.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默认128zset-max-listpack-value默认64。做排行榜时ZSet是标准答案ZINCRBY加分、ZREVRANGE取前N、ZRANK查名次一条龙。Set的集合运算能力经常被低估。共同关注用SINTER可能认识的人用SDIFF标签筛选用SUNIONSTORE把结果落盘再做分页。这类运算在数据量不大时非常划算因为计算发生在Redis内部省掉了把集合拉到应用层的内存和网络开销。类型典型场景要避开的操作String计数、会话、短配置大JSON整体读改写Hash对象属性、字段级更新HGETALL大HashList队列、最新N条LINDEX随机访问、LRANGE全量Set去重、交并差、标签SMEMBERS大集合ZSet排行榜、延迟队列、范围查询深offset分页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 HyperLogLogUV统计的误差换内存统计独立访客是个经典难题用Set精确去重一千万UV就是几百MB用HyperLogLog固定12KB标准误差0.81%。这个交换在绝大多数业务场景下是划算的因为UV数字本身带个百分之一的误差运营同学根本感知不到。用法极简PFADD uv:20240305 user1 user2PFCOUNT 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-04. 底层编码与内存同样的数据为什么别人省一半线上内存告警的时候最常见的解释是数据量涨了但实际情况往往是编码退化。同一批数据编码选对了占100MB选错了占300MB业务代码一行没改。4.1 编码转换的触发条件要背下来类型紧凑编码转换阈值默认转换后Stringint / embstr44字节rawHashlistpack128字段 或 单值64字节hashtableListlistpack128元素 或 单元素超限quicklistSetintset512个整数元素hashtableZSetlistpack128元素 或 单值64字节skiplist这些值都能通过CONFIG GET查到也能改。改之前想清楚调大阈值意味着更多数据走紧凑编码省内存但单次操作可能变慢因为listpack是线性扫描调小则相反。我的经验是默认值对大多数业务是合理的除非你明确知道自己的数据形态否则别乱动。一个高频误区是以为Hash的字段值可以随便长。实际上只要有一个字段超过64字节整个Hash就转hashtable。一个存用户信息的Hash如果塞了个头像URL经常超过64字节转换就发生了。解决办法是把这类长字段拆成独立key。4.2 大key识别先量出来再谈优化大key没有绝对定义通常按value超过1MB或集合元素超过5000作为经验线。它的危害不在于占内存而在于操作它的时候会长时间占用主线程。删除一个百万元素的Set如果直接用DEL主线程会卡住用UNLINK则是异步回收把释放动作放到后台线程。识别手段有几个redis-cli --bigkeys扫一遍能给出每种类型的最大keyMEMORY 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转成hashtableHGETALL要遍历整个哈希表并构造返回遇到大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是最省事的办法。检查项错误做法正确做法遍历键空间KEYS patternSCAN 0 MATCH pattern COUNT 1000取大Hash全量HGETALL keyHSCAN key 0 COUNT 100删大keyDEL keyUNLINK key多key批量跨slot的MGEThash tag绑定同slot或用pipeline集合全量SMEMBERS keySSCAN key 0 COUNT 100还有一个容易被忽略的点pipeline和事务的边界。pipeline只是把多条命令打包发送减少RTT它不保证原子性MULTI/EXEC保证原子但不保证全部成功执行过程中某条命令失败其余命令照样执行。真正需要要么全成功的语义得靠Lua脚本。这一点在做库存扣减、积分变更这类操作时尤其重要。最后分享一个我个人的习惯接手任何用到Redis的项目第一件事是跑一遍--bigkeys和看一遍慢查询日志再CONFIG GET maxmemory-policy确认淘汰策略。这三步下来基本能判断出这个实例的健康度和团队的使用水平。淘汰策略如果是noeviction而内存又设了上限那写满之后所有写操作都会报错这种配置在缓存场景里几乎一定是错的应该用allkeys-lru或volatile-lru。数据类型的选型没有标准答案只有在当前数据规模、访问模式和可靠性要求下最不坏的那个。我自己的判断顺序是先看读写粒度定基础类型再看量级估编码转换风险最后看可靠性要求决定要不要上Stream或者自己补确认机制。这套顺序用熟了大部分选型纠结在动手之前就能消解掉。