前阵子我们线上Redis有一次内存报警我第一反应是抓大Key结果抓出来一个让我很无语的对象一个被当成字符串来存的JSON里面塞了一个每天都在涨的数组。这个事的本质不是命令用错了而是数据类型选错了——把本该放进List或Set里做增量操作的数据强行塞进String里反复读改写内存越堆越高业务代码也越写越绕。Redis数据类型这件事看起来就是五张命令表背熟好像就能应付了但真正在项目里吃过亏之后才会明白数据类型其实是一套内存数据模型它决定了你能用什么命令、能支撑什么数据规模、会不会把主线程拖垮。这篇内容不是命令大全而是从数据结构、底层编码、业务场景、踩坑事故四个角度把Redis的数据类型完整拆一遍。适合刚学完安装、正准备深入使用的朋友也适合面试前想系统梳理“redis数据类型及命令”的读者。1. 类型选错项目为什么买单1.1 数据类型的本质是一套内存数据模型很多人对Redis数据类型的理解是“五组命令”比如String就是SET/GETList就是LPUSH/LPOP感觉学会命令就会用了。但换个角度想一下命令只是操作入口真正决定这些命令快不快、省不省内存的是命令背后的数据结构。String → 二进制安全的字节数组Hash → 字段与值的映射表List → 双向链表由紧凑块组合而成Set → 哈希表或整数集合ZSet → 跳表 哈希表这意味着同样一个“判断成员是否存在”的需求用Set的SISMEMBER是O(1)几百万数据也就是一次哈希查找但如果你非要用List来存LREM或遍历判断就变成了O(N)数据一大主线程卡顿是必然的。命令的复杂度根本是由数据结构决定的而不是你背了多少条命令能覆盖的。这也是为什么Redis官方把“数据类型”当作最核心的知识体系。你可以在客户端或者可视化工具比如RedisInsight、Another Redis Desktop Manager里直接看到每个key的类型图标但工具只能告诉你它是hash还是list不能告诉你这个类型选得对不对。1.2 选错类型的三个真实代价第一种代价是内存膨胀。最典型的例子把用户对象直接序列化成JSON字符串塞进String。这样做读起来确实一次性拿到全部字段但每次修改任意一个字段都只能把整个JSON读出来、改、再写回去旧值要等新值替换后才被回收。同一份数据用Hash存字段级更新内存占用可能只有String方案的几分之一尤其是小对象时Hash底层还有紧凑编码加持。第二种代价是查询阻塞。Redis是单线程模型一个慢命令会堵住后面所有请求。大Hash上执行HGETALL、大Set上执行SMEMBERS一次性返回几十万个元素网络传输和序列化都能让主线程卡上好几秒。线上出过一次事故之后我对所有“全量拉取型”命令都特别警惕。第三种代价是业务代码越来越绕。比如想用Redis做一个抽奖去重本来Set的SADD SPOP就能干净解决有人非用List LREM去模拟代码里还要处理已弹出元素的判断写起来别扭跑起来也没效率。1.3 为什么这也是面试必考点Redis数据类型是面试里绕不开的一环但真正拉开差距的不是“Redis有哪几种数据类型”这种送分题而是连环追问String底层是什么为什么用SDSHash在什么条件下用ziplist/listpack什么条件下转hashtableZSet为什么要用跳表而不是红黑树这些问题全部指向底层数据结构。如果你理解数据类型是数据模型而不是命令字典就能自然串起一条线每个key在内存里长什么样 → 命令复杂度从哪来 → 数据量变大后编码怎么切换 → 业务场景该怎么选型。这套知识网络既能应对面试也能在真实项目里帮你避开上面那三种代价。2. 五种基础类型拆解从数据结构到业务落地2.1 String别只当字符串用String是Redis里最简单的类型本质是一个二进制安全的字节数组最大512MB。它内部有三种编码整数用int短字符串用embstr长字符串用raw。这个细节后面第4章会展开。核心命令就是那些SET、GET、MSET、MGET、SETNX、SETEX、APPEND、GETRANGE以及容易被忽略的INCR/DECR/INCRBY。 SET login:count 0 OK INCR login:count (integer) 1 SET lock:order:1001 1 NX EX 30 OK典型场景有三类。第一是缓存最无脑也最常用。第二是计数器点赞数、访问量、库存扣减INCR本身就是原子操作省去你先GET再SET的并发问题。第三是分布式锁SET key value NX EX seconds是标准实现NX保证不覆盖已有锁EX防止持有锁的进程宕掉导致死锁。这里有个我踩过的坑很多人用String存JSON对象这在小数据量下没毛病但一旦这个对象有“频繁更新某个字段”的需求String就得全量读改写。比如购物车每次加购都是GET → 解析 → 拼数组 → SET并发一上来就丢更新。后面第5章我会专门讲这个事故。所以String适合“整体写入、整体读取、不拆字段”的数据不适合“需要局部更新”的数据。2.2 Hash对象数据的最佳容器Hash是一个field-value映射表你可以把它理解成Redis里的“对象”。它对应到内存里是小数据时的紧凑列表listpack大数据量时的真正的哈希表hashtable。核心命令 HSET user:1001 name 张三 age 30 city 杭州 OK HGET user:1001 name 张三 HINCRBY user:1001 age 1 (integer) 31 HGETALL user:1001 1) name 2) 张三 3) age 4) 31最典型的场景就是存对象用户信息、商品详情、配置项。为什么比String存JSON更好因为Hash支持字段级读写你只想改年龄就只发一个HINCRBY或HSET不需要把整个对象掏出来。另外Hash还特别适合做购物车key是用户IDfield是商品IDvalue是数量。加购就是HINCRBY删除就是HDEL查购物车只有几十个field性能没压力。Hash也有自己的注意事项。HGETALL看起来方便但field数量一涨到几十万甚至上百万这个命令就是灾难。正确做法是用HSCAN分批迭代一次取一部分别想着一把梭。另一个是field的命名也尽量短field本身也是要占内存的长字段名乘以百万级就是很可观的开销。2.3 List既是列表也是队列List在Redis 3.2之后用quicklist实现本质上是一个双向链表但每个节点都是一段连续内存的压缩块兼顾了两端插入的灵活性和内存利用率。核心命令 LPUSH feed:user:1001 article:101 RPUSH queue:task job:1 BRPOP queue:task 0 1) queue:task 2) job:1 LRANGE feed:user:1001 0 9List最经典的用法是队列和时间线。LPUSH BRPOP就是先入先出队列BRPOP能阻塞等待非常适合异步任务分发。比如你有一个任务池生产者LPUSH消费者BRPOP天然就支持多个消费者竞争消费。另一个常见场景是feed流比如用户最新动态列表LPUSH新内容用LTRIM只保留最近100条就能控制列表长度。这里要提醒一句LTRIM是很值钱的命令它能在列表增长时把头部或尾部的旧数据裁掉很多“只关心最近N条”的业务都该用它。别忘了List的读取LRANGE 0 -1会一次性返回全部元素对于很长的列表这也是阻塞源。取最近几条请给确定的范围别偷懒。2.4 Set集合运算带来的业务能力Set是无序、去重的字符串集合。底层在元素全为整数且数量不多时用intset否则用hashtable。由于它是哈希结构判断某个成员是否存在是O(1)这是List替代不了的。核心命令 SADD user:1:tags 技术 生活 旅行 (integer) 3 SISMEMBER user:1:tags 技术 (integer) 1 SINTER user:1:tags user:2:tags 1) 技术 SPOP lucky:draw 1Set的业务场景相当广标签系统给文章打标签、点赞用户去重、抽奖池、关注关系。最有用的是集合运算SINTER可以算两个人的共同好友SUNION做推荐候选集SDIFF算差集比如“关注了你但你没关注他”。坑也有SMEMBERS和HGETALL是同一类问题成员很多时别全量拉取用SSCAN迭代你要的是“随机抽一个”用SRANDMEMBER或SPOP而不是SMEMBERS取完再在代码里随机后者白白浪费网络传输。另外如果业务需要对成员排序Set就直接出局了那是ZSet的事。2.5 ZSet排行榜与延迟队列的默认解法ZSet是有序集合每个成员关联一个double类型的scoreRedis按score排序。底层在小数据时用listpack数据量大了用跳表哈希表哈希表负责O(1)定位成员跳表负责范围查询。核心命令 ZADD ranking:game 1000 player:1 ZINCRBY ranking:game 50 player:1 ZREVRANGE ranking:game 0 9 WITHSCORES ZRANGEBYSCORE delay:queue -inf now LIMIT 0 100经典场景第一个就是排行榜。分数作为score玩家ID作为memberZINCRBY加分ZREVRANGE取前N名ZSCORE看单人分数全是一行命令的事。第二个是延迟队列score存任务的执行时间戳生产者ZADD消费者用ZRANGEBYSCORE把score小于当前时间的任务取出来执行。第三个是滑动窗口限流把每个请求的时间戳ZADD进一个key窗口内请求数就是ZCOUNT。ZSet的注意点比较隐蔽第一score是双精度浮点不要把需要精确到分的金额直接放进去第二member尽量短因为跳表节点会存储member的完整副本第三ZRANGEBYSCORE批量取到期任务时一次取多少要控制配合LIMIT和ZREM分批处理别一下捞出十万个任务来消费。3. 很多人用不上的衍生类型位图、基数统计、地理与流3.1 Bitmaps用最小内存记亿级状态Bitmaps不是一种独立的数据结构它底层就是String但是按位操作。你可以把每个bit当成一个开关0或1代表某个状态。核心命令是SETBIT、GETBIT、BITCOUNT、BITPOS、BITOP。 SETBIT user:sign:2025-01 100 1 (integer) 0 GETBIT user:sign:2025-01 100 (integer) 1 BITCOUNT user:sign:2025-01我见过最典型的使用场景是签到和日活统计。比如1亿用户只需要1亿个bit约占12.5MB内存就能记录“今天谁来过”。如果用Set存用户ID哪怕只存10万活跃用户内存也要几MB到几十MB用户量再涨就没法比了。Bitmaps也能做位运算BITOP AND/OR可以把某几天的活跃用户做交集/并集直接算出连续活跃或者月活。要注意的是Bitmaps的offset不能超过String上限512MB对应约43亿bit对绝大多数业务够用了。单个key太大会造成迁移、持久化成本高设计时尽量按天分key。3.2 HyperLogLogUV统计的近似答案HyperLogLog简称HLL是用来做基数统计的也就是“有多少个不重复的元素”。它最大的特点是固定占用很小的内存标准误差0.81%。 PFADD uv:2025-01-01 user:1001 user:1002 user:1001 (integer) 1 PFCOUNT uv:2025-01-01 (integer) 2 PFMERGE uv:week uv:2025-01-01 uv:2025-01-02 OK如果你的业务是统计每日UV用Set确实精确但量级到千万甚至亿级时内存会吃紧。HLL每个key最多约12KB就能统计海量去重数配合PFMERGE还能把多天数据合并看作一个大周期去重。代价是它不是精确值也不是百发百中0.81%的误差在绝大多数业务指标上都能接受。用HLL要清楚两条限制第一它只告诉你“大概多少个不重复”不能告诉你“有哪些不重复”第二你无法删除某个元素。需要用“黑名单精确剔除某些用户”的场景HLL不适用老老实实Set。3.3 GEO距离计算的Redis版GEO是Redis 3.2加入的本质上是把经纬度编码成一个score塞进ZSet里。你可以向它添加位置、算两点距离、查某个点附近的其他点。 GEOADD stores:hangzhou 120.1536 30.2875 store:a GEODIST stores:hangzhou store:a store:b km 2.315 GEOSEARCH stores:hangzhou FROMLONLAT 120.15 30.28 BYRADIUS 5 km ASC WITHDIST典型场景是“附近的人”“附近的门店”。命令层面GEOADD添加位置GEODIST算距离GEOSEARCH按半径找点这几个就够日常用了。因为底层是ZSet你可以用ZREM删除某个成员也可以用ZSCORE反查编码过的坐标。坑点在于GEO背后的score是geohash编码如果你直接用ZRANGE这类命令去遍历拿到的不是经纬度而是一串整数。所以业务里不要混用GEO命令和ZSet命令去操作同一个key容易把数据搞乱。3.4 Stream比List更可靠的消息队列Stream是从Redis 5.0开始独立的类型专门解决“用List做消息队列但不够可靠”的痛点。List的LPUSH BRPOP是抢消息模式消费者一旦在业务处理中途挂掉消息就再也找不回来了。Stream引入了真正的消费组机制XADD追加消息XGROUP创建消费者组XREADGROUP让组内消费者各自读到不重复的消息XPENDING查看未确认消息XACK确认已处理。 XADD order:queue * orderId 1001 XGROUP CREATE order:queue group:pay $ XREADGROUP GROUP group:pay consumer:1 COUNT 1 STREAMS order:queue 它带来的核心能力是消息确认和消费位点管理消费者崩了消息还在Pending列表里其他消费者可以继续处理处理完了手动XACKRedis才会认为消息被消费过。这比List盲抢可靠得多比引入一套独立的MQ又轻量得多。要注意Stream不是无限存储消息堆积会一直占内存。业务上要么XADD时带MAXLEN限制长度要么定期调用XTRIM清理历史消息。4. 底层编码机制为什么同样数据内存差好几倍4.1 用OBJECT ENCODING看穿一切Redis暴露了一个非常方便的命令OBJECT ENCODING能直接看到某个key当前在内存里的编码方式。 SET age 18 OBJECT ENCODING age int SET name abcdef OBJECT ENCODING name embstr HSET user:1 name a age 1 OBJECT ENCODING user:1 listpack我第一次看到这个命令输出时还挺惊讶的原来同一个String类型存整数是一种编码存短字符串是另一种存到长字符串又是一种。这个视角对排查内存问题太重要了——同样叫String内部差别很大。需要明确的点编码是由Redis根据value特征和数据量自动决定的开发者不能直接指定某个key必须用listpack还是hashtable但你可以通过修改配置阈值影响什么时候发生切换。4.2 每种类型的“变身”条件与配置阈值不同的类型有不同的变身规则我把核心变化整理成了下面这张表类型小数据量编码大数据量编码关键配置变化原因Stringint / embstrraw无由长度自动决定字符串越长越需要单独分配内存Hashlistpackhashtablehash-max-listpack-entries 128hash-max-listpack-value 64小对象紧凑大对象哈希查询更快Listquicklist节点用listpackquicklistlist-max-listpack-size双向链表两端操作快节点内连续存储Setintsethashtableset-max-intset-entries 512全整数时排序数组二分查找内存极省ZSetlistpackskiplist hashtablezset-max-listpack-entries 128zset-max-listpack-value 64跳表支持范围查询哈希表支持精确查找解释一下为什么小数据时不用大结构listpack是一整块连续内存元素挨着放指针开销几乎为零intset是一个排序好的整数数组用二分查找就能判断成员是否存在。这种紧凑编码下几十个字段的Hash可能只要一两百字节。一旦超过阈值Redis为了维持操作复杂度会把数据搬迁到hashtable或skiplist这种更“重型”的结构查询变快了但每个节点都带了指针等额外内存开销。4.3 编码选择的工程启示这条规律落到工程上有一个很实用的判断如果你的Redis里大量是“小key、短value、小集合”压缩编码能省出非常可观的内存。尤其是缓存场景上千万个几字节的value如果都走raw甚至是hashtable内存开销可能翻好几倍。我曾经处理过一个内存优化一批用户标签每个用户平均10个标签原来全用String存JSON内存一天天涨。后来改成Set并且保证标签都是短字符串内存占用直接降了60%以上。这就是编码机制的价值。另外一个容易被忽略的点是编码切换的代价。一个Hash从listpack变成hashtable意味着要把旧数据结构里的数据整体搬迁到新结构期间有短暂的内存复制和CPU消耗。如果业务正值写入高峰期可能出现毫秒级抖动。所以在设计阶段就要预估单个key的数据规模比如知道某个Hash未来会有几十万field就默认它已经是hashtable级别从第一天起就按大数据量去设计读写命令别等它切换之后再优化。5. 选型与排错我踩过的三个数据类型事故5.1 HGETALL大Hash拖垮主线程那次事故发生在配置中心。为了图省事把所有业务配置放在一个Hash里key是配置项名value是配置值一开始只有几千个field相安无事。后来配置项增长到几百万客户端每次启动会拉全量配置代码里直接HGETALL一拉一次就拿回百万级field序列化和网络传输直接把Redis主线程打出一串慢日志。排查过程也很直白先用redis-cli --bigkeys扫了一遍看到那个巨大的hash再配合慢日志定位到HGETALL命令。修复分两步第一客户端全量加载改成HSCAN分批拉取第二把key按照业务域拆成多个小Hash避免单key过大。从那以后我对集合类型的所有“全量命令”都保持了警惕。5.2 用String模拟数组导致并发覆盖另一个事故是购物车。当时开发图简单把购物车商品ID拼成JSON数组存进String每次加购就先GET、解析、追加、再SET。平时人少没事活动大促一上线并发请求同时GET到同一个旧值各自追加后再SET后来的覆盖先来的用户购物车里商品莫名消失。这个问题的根源就是String不支持局部更新。修复很简单换成了Hashkey是用户IDfield是商品IDvalue是数量加购直接用HINCRBY删除用HDEL并发问题烟消云散。这个案例也印证了第2章的观点——String适合整体读写有增量写需求就必须换类型。5.3 Set/ZSet把业务绕成死结还有一个同事踩的坑需求是做排行榜他选了Set因为“要去重”。去重确实没问题但Set是无序的做排行榜必须在代码里把所有成员取出来排序。一开始几百人还能跑用户量到几十万后每次拉全量Set再排序接口直接超时。后来换成ZSet分数做scoreZREVRANGE 0 99就拿到了前100名代码量反而少了。这个案例让我意识到选类型不看“数据结构有什么”而看“业务怎么读怎么写”。数据是标量还是对象要不要排序要不要范围查询要不要集合运算——这决定了类型归属。5.4 我现在的选型习惯先画数据模型再选命令踩过这些坑之后我现在接到Redis相关需求第一件事不是想命令而是先画一个数据模型草稿。数据是单个值还是一个对象是序列还是无序集合还是带权重的有序集合访问模式是整体读还是局部读量级预计是多少这里给你一张我实际在用的选型表算是压箱底的东西业务场景推荐类型一句话理由缓存单个值、计数器、分布式锁String简单直接INCR原子对象、用户属性、购物车Hash字段级读写局部更新无压力消息队列、动态列表、时间线List天然队列BRPOP阻塞消费去重、标签、共同好友、抽奖Set去重集合运算SISMEMBER O(1)排行榜、延迟任务、滑动限流ZSetscore排序范围拉取一行命令签到、在线状态、日活统计Bitmaps一个bit一个状态亿级用户内存极低大规模UV统计可容忍误差HyperLogLog固定约12KB误差0.81%附近的人、门店距离GEO经纬度编码进ZSet半径查询内置可靠消息队列、消费者组Stream有ACK机制消息不丢最后再分享一个我自己的体会数据类型不是你背完就结束的知识点它是你对“这份数据在内存里怎么存、怎么读、怎么演”的理解。我现在的习惯是每个类型都至少亲手在redis-cli里写上几十条命令再用OBJECT ENCODING观察它的内存形态变化遇到新需求先画数据模型再动手。这套方法帮我挡掉了至少一半的返工也希望对你有点用。