Redis 这东西搞后端的基本都躲不开。但很多人用了两三年翻来覆去就是SET、GET、DEL三件套顶多加个EXPIRE。一旦问到 Redis 到底有哪些数据类型、每种类型的底层结构是啥、什么场景该选哪个就含糊了。这篇文章就把 Redis 数据类型这件事从头到尾扒一遍从五种基础类型到扩展类型从底层编码到实际坑点一次说透。不管是刚接触 Redis 的新手还是准备面试的老兵都能从中捞到点干货。1. Redis 数据类型全景图五朵金花和它们的新兄弟1.1 为什么数据类型值得单独拿出来讲很多初学者会把 Redis 当成一个“key-value 数据库”脑海里浮现的画面就是一个大字典key是字符串value也是字符串。这个理解不算错但太粗了。Redis 真正的强大之处恰恰在于它的value不是单纯的字符串而是具有特定结构和操作语义的数据类型。这意味着什么举例来说如果你用普通的 key-value 存储记录一个博客文章的点赞用户 ID 列表你可能得自己把数组序列化成 JSON 字符串存进去每次点赞要把整个字符串取出来、反序列化、修改、再序列化、写回去。而如果用 Redis 的Set类型一个SADD命令就搞定了而且天生去重。这就是数据类型的价值它把常见的数据结构和操作逻辑下沉到了服务端让客户端代码变得极其简洁同时性能还甩自定义方案几条街。所以搞懂 Redis 数据类型本质上是在搞懂 Redis 能替你干哪些活、怎么干最划算。1.2 从基础类型到扩展类型一张表看全先放一张全景表后面逐一拆解类型底层编码典型核心特征典型场景Stringint / embstr / raw二进制安全最基础缓存、计数器、分布式锁Hashziplistlistpack / hashtable字段级别的操作对象存储、商品信息Listquicklist双向链表 压缩列表消息队列、时间线Setintset / hashtable无序、去重、集合运算标签、共同关注、抽奖ZSetziplistlistpack / skiplistdict有序、可排序、带权重排行榜、延迟队列Bitmap基于 String 的位操作位级别操作省内存签到、在线状态、布隆过滤器HyperLogLog稀疏/稠密编码基数统计误差可控UV 统计Geo基于 ZSet 的编码地理位置计算附近的人、LBSStreamstream 结构消息队列可持久化消息中间件、事件流注意表格里的“底层编码”这个是理解 Redis 内存模型的关键后面专门开一节细讲。先把整体印象建立起来Redis 的数据类型不是孤立的概念每种类型都有精心设计的内部编码目的是在内存占用和操作效率之间找平衡。2. 踩坑最多的两个类型String 和 Hash 的深度拆解2.1 String 不只是存字符串三个隐藏用法先说 String。它是 Redis 最基础的类型也是绝大多数人用的第一个类型。表面上看就是存字符串但实际上 String 在 Redis 内部有三种编码方式int当 value 是整数时Redis 直接以整数形式存储不做字符串转换省内存且支持原子自增。embstr短字符串通常小于 44 字节内存连续分配读写快。raw长字符串需要两次内存分配但无长度限制。很多人不知道的是String 类型除了存文本还有三个高频用法计数器。INCR、DECR、INCRBY这些命令是原子操作底层就是int编码在起作用。我做秒杀系统的时候就用 Redis 的DECR做库存扣减单线程模型保证不会超卖。需要注意INCR操作如果 value 不是整数会返回错误所以不要把用户 ID 这种字符串硬当成计数器用。对象序列化存储。把 Java/Python 对象序列化成 JSON 或二进制然后存到 String 里。这里有个容易被忽略的问题Redis 的 String 是二进制安全的也就是说你存什么字节它就能原样吐出来什么字节。所以序列化框架随便选Jackson、Protobuf、Kryo都行。位图操作的载体。实际上 Bitmap 在底层就是一个 String只是按位来解释。后面单独说。用 String 的时候我建议养成一个习惯key 的命名要带业务前缀比如user:profile:1001、product:stock:8888。这是无数血泪教训换来的Redis 的 key 一旦多起来没有规范的命名排查问题能让你怀疑人生。2.2 Hash 比 String 强在哪字段级操作才是核心优势Hash 在 Redis 里的样子类似一个“小字典”一个 key 对应一个 field-value 集合。它最核心的价值是可以把对象的多个属性存在一个 key 下并且单独操作某个字段。举个例子。用户信息有昵称、头像、积分、等级四个字段。如果你用 String 存得序列化成一整条更新积分时要把整条取出来改完再写回去。如果用 HashHSET user:1001 nickname 老王 avatar /a.png points 1000 level 5 HINCRBY user:1001 points 100这种操作方式的优势有两个一是省带宽只传输变更的字段而不是整个序列化后的对象二是省 CPU不需要反序列化整个对象。我实测过缓存一个包含 20 个字段的对象Hash 的更新性能比 String 序列化方式能提升一个数量级当然前提是字段确实需要单独更新。Hash 有个典型的大坑需要提醒HGETALL慎用。如果这个 Hash 很大比如几万个字段HGETALL会把所有字段和值一次性返回网络 IO 直接拉满。建议用HSCAN分批获取或者设计时就把大 Hash 拆分。另外记住Redis 的 Hash 底层有两种编码字段少且值小时用listpack新版本替代了 ziplist一条连续内存省空间字段多了以后自动升级为hashtable空间换效率。这个升级是自动的不需要你干预但理解了能帮你解释“为什么我的 Hash 内存突然变大了”。2.3 序列化选择无论用什么框架都要记住“兼容性”三个字缓存场景逃不开序列化。Redis 客户端比如 Spring Data Redis默认的序列化器是 JDK 自带的存进去的东西是带类型描述的一长串字节肉眼不可读占空间还大。我见过生产环境 Redis 内存暴涨最后排查发现是默认 JDK 序列化搞的鬼。实践中的做法一般是JSON 序列化可读性好方便排查数据但空间开销略大没有类型信息。Protobuf 序列化体积小、速度快但二进制不可读排障要靠工具。Kryo / Hessian体积也小但要注意版本兼容性跨语言不友好。踩过几次坑之后我的原则是缓存数据用 JSON 序列化追求可读性队列消息用 Protobuf追求体积和性能。另外不管用哪种序列化一定要在序列化后的数据里带上版本标识或类型标识不然以后升级结构的时候老数据反序列化直接报错那场面相当酸爽。3. List、Set、ZSet集合操作的三种打开方式3.1 List不只是队列还能当栈和分页用List 在 Redis 里是双向链表支持头尾插入、弹出按下标取值等操作。它的内部编码是quicklist可以理解为“多个压缩块组成的链表”兼顾了内存紧凑和两端操作的效率。List 最常见的玩法是消息队列生产者LPUSH消费者BRPOP。BRPOP是阻塞式弹出队列为空时挂起等待避免了浪费 CPU 轮询。这个模式简单可靠很多小规模系统就直接用 Redis List 当消息队列用连 RabbitMQ 都省了。但 List 有个能力很多人忽略了分页查询。LRANGE key 0 9能取前 10 条配合LPUSH写入的新数据排在最前面天然适合做“最新动态列表”。我在一个社区项目里就用LPUSH LTRIM组合维护了一个定长的最新评论列表每条评论 push 进去后再LTRIM截断到最近 500 条内存控制得死死的。List 的坑主要在误用LINDEX。它是 O(N) 操作如果列表特别长按索引访问会非常慢。只要求按序访问头部尾部就用LPOP/RPOP千万别拿LINDEX当数组用。3.2 Set去重是表面集合运算才是灵魂Set 是无序不重复集合内部编码可能是intset全是整数且数量少时或hashtable。去重是它的基本功能SADD重复添加不会成功这个特性能干嘛做抽奖、做签到去重、做关注列表。但 Set 真正的价值在于集合运算SINTER交集求两个用户共同关注的博主。SUNION并集合并多个标签下的文章。SDIFF差集找出用户已关注但博主没回关的。这些运算命令在服务端直接完成客户端只要拿到结果就行。换成 MySQL 做同样的功能要么嵌套查询要么在应用层做 Set 交集代码复杂度和性能完全没法比。做推荐系统或者社交功能的时候Redis 的 Set 集合运算是非常趁手的武器。SMEMBERS命令需要注意它会把 Set 里的所有元素取出来如果集合非常大十万级别内存和带宽都会难受。建议改用SSCAN游标式遍历或者干脆别做全量取出的操作。3.3 ZSet 是有序的真相跳表 哈希的组合拳ZSet有序集合是 Redis 里最有“技术含量”的一个类型每个成员都关联一个分数score按分数排序。它的底层是skiplist dict的组合dict 保证 O(1) 的成员查找skiplist 保证分数排序和范围查询的高效性。这个设计让我想起小时候查字典的方法先翻到大概的页再逐页找。跳表就是一种多级索引链表可以快速跳过不需要遍历的节点。相比平衡树跳表的实现简单很多而且范围查询比如取分数段内的元素天然友好。ZSet 的经典应用场景排行榜。游戏玩家战力排行ZADD rank 5000 player_1然后用ZREVRANGE rank 0 9 WITHSCORES取前十名。分数更新也简单ZINCRBY rank 200 player_1直接加分自动重新排序。延迟队列。这个用法比较隐蔽但很实用把任务执行时间戳作为 score消费者轮询ZRANGEBYSCORE queue -inf now LIMIT 0 10拿到所有到期的任务执行执行完ZREM删掉。我拿它做过定时任务调度没有再引入额外的消息队列组件效果很好。ZSet 的坑是分数是浮点数精度有限。如果分数是整数千万以内的值没问题但超过2^53约 900 万亿就可能丢失精度。我在做积分排行时用的是“积分 * 1e6 时间戳偏移”的方式编码分数不用浮点而是整数运算避开了这个坑。4. 藏在进阶缝里的新类型Bitmap、HyperLogLog、Geo、Stream4.1 Bitmap用最小的内存干最大的事Bitmap 不是独立的数据类型它本质上是 String 类型上的位操作扩展。可以用SETBIT、GETBIT、BITCOUNT等命令按位操作。一个位就是一个 0/1 标记8 个位组成一个字节理论上存储 1 亿用户的签到状态只要约 12MB 内存。最典型的应用是签到系统和在线状态标记。一年 365 天给每个用户建一个 365 位的 BitmapSETBIT sign:2024:1001 0 1表示第 0 天签到了BITCOUNT sign:2024:1001统计用户年内签到天数。一行命令的事换成 MySQL 表存储光索引就够喝一壶的。但 Bitmap 的命令要注意位是从 0 开始编号的日常习惯的“第 1 天”要映射成“偏移量 0”这是最容易写错的地方。另外BITPOS命令可以快速找到第一个值为 0 或 1 的位我拿它做过“连续签到天数”的计算从今天往前找第一个未签到的位就知道连续签到了多少天。4.2 HyperLogLogUV 统计的作弊器如果你需要统计一个页面的 UV独立访客数传统做法是在数据库来一条记录或者用 Set 存用户 ID。数据量小没问题百万级 UV 的时候Set 内存就开始吃紧了。HyperLogLog 可以做到固定内存下统计海量基数无论存多少元素每个 key 最多占 12KB 内存标准误差在 0.81% 左右。用PFADD添加元素PFCOUNT统计基数。对一个日活千万的产品来说0.81% 的误差完全可接受省下的内存则是实打实的。有个点必须说清楚HyperLogLog 是“近似统计”不支持精准去重查询也不能反向枚举元素。如果你需要知道“具体哪些用户访问了”别用这个老老实实 Set 或落库。这是一个典型的“工具选型要看场景”的案例。4.3 Geo附近的人是怎么实现的Redis 3.2 开始提供了地理位置相关的类型GEO。它底层用的是 ZSet 结构只不过 score 是把经纬度通过 GeoHash 算法编码后得到的值。命令有GEOADD、GEODIST、GEOSEARCH等。实现“附近的人”功能GEOADD user_location 116.39 39.91 user_1添加用户位置。GEOSEARCH user_location BYLONLAT 116.39 39.91 BYRADIUS 5 km查询周边 5 公里的用户。底层 GeoHash 有个值得留意的特性它把地球划分为网格位置相近的点编码也相近但存在边界问题——两个其实很近的点可能落在相邻网格、编码距离却很远。所以严格来说GEOSEARCH是先筛候选集再算精确距离但边界点还是有罕见误差。对 LBS 这种“近似即可”的场景够用了。真正对精度要求苛刻的场景还是上 lucene 之类的专业引擎吧。4.4 Stream官方钦定的消息队列姿势Redis 5.0 引入了 Stream一个真正的、可持久化的消息队列模型弥补了之前 List 队列的不足。它支持消息 ID、消费者组Consumer Group、消息确认ACK和 Pending 机制语义上接近 Kafka但轻量得多。Stream 的完整机制展开讲能写一本书这里只说我实际项目中用到的核心流程XADD mq * field value往 stream 追加消息。XREADGROUP GROUP group1 consumer1 COUNT 10 BLOCK 2000 STREAMS mq 消费者组读取新消息。XACK mq group1 msg_id处理完后确认消息。相比 List 队列Stream 最大的提升是消费者组同一个消息可以被多个消费端分布式消费且不会被重复消费通过 ACK 机制保证。它还支持 XAUTOCLAIM 把超时未确认的消息重新投递给其他消费者解决“消费者宕机导致消息丢失”的老大难。5. 数据类型的底层实现与内存优化实践5.1 底层编码转换的规律前面提到过Redis 内部为每种数据类型设计了多种编码方式简单数据用小内存的紧凑结构大数据才升级为高级结构。这个“升级”机制非常值得理解因为它直接决定了你的内存开销。具体转换规则类型紧凑编码升级条件默认配置升级后编码Hashlistpack字段数 128 或单字段长度 64 字节hashtableZSetlistpack成员数 128 或 score 长度 64 字节skiplistSetintset元素全为整数且数量 512hashtableStringembstr长度 44 字节raw这里有个关键认知编码升级是不可逆的。一个 listpack 编码的 Hash 一旦升级为 hashtable即使后面删到字段数只剩 10 个也不会退回 listpack。这会导致一种情况你往一个 Hash 里临时塞了一大堆数据之后删除大部分内存却不会显著下降。生产环境维护 Redis 内存时如果发现某些 key 缩水后内存不见少往往就是这个原因。5.2 内存优化三板斧做完 Redis 内存优化的一个项目之后我总结出几条最实用的经验优先使用紧凑编码。写入 Hash 和 ZSet 时尽量控制单一 key 的大小让数据停留在 listpack 阶段。比如商品详情按“商品 ID 分段”存储不要让一个 Hash 膨胀到上万字段。合理配置 maxmemory-policy。内存打满时 Redis 的淘汰策略直接决定系统稳定性。allkeys-lru适合纯缓存volatile-ttl适合某些 key 要保活的场景。建议关闭noeviction否则写入会直接报错把缓存故障升级成业务故障。用 Redis 4.0 的 MEMORY 命令排查。MEMORY USAGE key能精确看到单个 key 占多少字节MEMORY STATS看全局分配情况。我经常在预发环境跑一遍全量 key 的MEMORY USAGE找出内存占用 top N优化效果立竿见影。还有个小技巧短 key 也占内存。Redis 的 key 本身也是字符串每一条都要存储并计算哈希。十万个 key 里的 key 名称每少一个字节总共就能省 100KB 左右。所以 key 命名在可读性和长度之间要平衡别写出user:profile:info:extra:detail:1001这种丧心病狂的长 key。6. 面试考点和实际项目中的经典坑6.1 缓存三大问题与数据类型的关系面试高频题“缓存穿透、缓存击穿、缓存雪崩”和数据类型的关系远比想象中大。缓存穿透查询一个不存在的 key请求直达数据库。解决思路是缓存空值用 String 存特殊标记或者用布隆过滤器。布隆过滤器可以基于 Bitmap 实现一个位数组加几个哈希函数就够了非常契合 Redis。如果数据量不大直接在 Redis 里用 Bitmap 手写一个也行命中判断的时候把误判率调低就行。缓存击穿热点 key 过期瞬间大量请求打爆数据库。解法是互斥锁而互斥锁要用到 Set 的SETNX或者SET NX EX组合实现。或者干脆逻辑过期——value 里存过期时间戳实际数据不设 TTL异步线程刷新缓存。这两种方案的实现都依赖数据类型属于典型的“类型选对方案做对”。缓存雪崩大量 key 同时过期数据库直接跪。预防措施是给过期时间加随机偏移量还有一个办法是热点 key 永不过期、用 ZSet 记录每个 key 的逻辑过期时间做异步续期。把 ZSet 当“定时任务表”用这里也是经典案例。6.2 分布式锁的正确打开方式分布式锁是 Redis 面试的常客也是工程里最容易出“看起来对实际有坑”的部分。最常见的错误版本是用SETNX加锁然后忘记释放或者释放错锁——在释放之前必须校验是不是自己的锁。正确做法一句话给锁的 value 设一个唯一标识释放锁时用 Lua 脚本校验并删除。而 Lua 脚本的原子性保障正是基于 Redis 单线程执行模型的。数据类型在这里的参与方式是锁本身只是一个 Redis String key但 setnx 的原子语义、ex 过期时间都是 String 类型命令范围内的能力。另外一个加分项是在代码里实现“可重入锁”——用 Hash 类型存锁的持有次数每次重入HINCRBY增计数释放时递减到 0 才真正删除。这是 Redisson 的实现思路面试时说出来是加分的。6.3 可视化客户端和运维排障的实用建议演进到运维视角很多人习惯装一个 Redis Desktop Manager 或者 Another Redis Desktop Manager 看数据。这类工具对看 String、List 没问题但对看 Hash 字段、ZSet 分数结构的时候建议关注官方 RedisInsight它对 Stream、Geo 这些高级类型的可视化做得更到位。排查线上问题时我建议按这个顺序来INFO memory看总内存和碎片率。MEMORY USAGE key定位大 key。SLOWLOG GET看慢命令重点揪出KEYS *这种全量扫描。开启慢日志的阈值建议设为 100ms 以下线上业务 10ms 以上的命令就得留意了。还有一个排障杀手锏Redis 6 以上推荐使用ACL给不同业务线创建不同权限的用户避免一个同事误操作FLUSHALL让整个集群数据蒸发。这个事故我亲眼见过一次恢复完成后全组人冒冷汗。6.4 序列化报错的经典场景Redis 使用中最多见的异常之一就是SerializationException。基本套路是数据写入时用一种序列化器读取时用了另一种结果反序列化失败。Spring Data Redis 环境下如果 RedisTemplate 的 key/value Serializer 配置不一致就会出现这种诡异问题。解决方案非常简单粗暴全局统一配置GenericJackson2JsonRedisSerializer并在序列化对象里带上class类型信息。存的时候有类型取的时候能精确还原。注意一点用 Jackson 序列化时不要用匿名内部类否则反序列化直接扑街。这个坑我踩过网上查了半小时才意识到类是匿名的、没有实际的类名可用。另外一个序列化的隐蔽坑是对象里加了新字段。线上老缓存数据没有新字段代码里新对象有非空校验反序列化时新字段为 null直接 NPE。所以缓存对象的结构变更要谨慎处理老数据——要么版本号隔离要么加默认值确保老数据兼容。实操总结选型时的三步决策法自己摸索了这么多年我总结出一个三步决策法每次设计 Redis 数据存储方案都直接套用第一步先想清楚数据的操作模式是读多写少还是写多读少是整体替换还是局部更新 第二步再明确数据结构的需求需要排序吗需要去重吗需要范围查询吗 第三步最后对照类型表选型局部更新选 Hash排序选 ZSet去重算交集选 Set位标记选 Bitmap近似基数统计选 HyperLogLog消息队列选 Stream。记住没有一种类型能通吃所有场景类型选错后面性能优化和代码重构都是加倍偿还。Redis 的学习曲线并不陡峭但数据类型的底层认知决定了你是在“用 Redis”还是只是“会用 Redis”。我个人把 Redis 数据类型当成一个工具箱来研究每次遇到新的存储业务先把五种基础类型过一遍再翻扩展类型思路清晰了很多。这篇文章里的每一个坑和经验都是真金白银买来的希望你在用 Redis 的路上能绕开我踩过的雷。 
长河君 · 2026/10/9 7:05:36 · 阅读 1.2k Redis数据类型全解析：底层编码、场景选型与避坑指南
Redis 这东西搞后端的基本都躲不开。但很多人用了两三年翻来覆去就是SET、GET、DEL三件套顶多加个EXPIRE。一旦问到 Redis 到底有哪些数据类型、每种类型的底层结构是啥、什么场景该选哪个就含糊了。这篇文章就把 Redis 数据类型这件事从头到尾扒一遍从五种基础类型到扩展类型从底层编码到实际坑点一次说透。不管是刚接触 Redis 的新手还是准备面试的老兵都能从中捞到点干货。1. Redis 数据类型全景图五朵金花和它们的新兄弟1.1 为什么数据类型值得单独拿出来讲很多初学者会把 Redis 当成一个“key-value 数据库”脑海里浮现的画面就是一个大字典key是字符串value也是字符串。这个理解不算错但太粗了。Redis 真正的强大之处恰恰在于它的value不是单纯的字符串而是具有特定结构和操作语义的数据类型。这意味着什么举例来说如果你用普通的 key-value 存储记录一个博客文章的点赞用户 ID 列表你可能得自己把数组序列化成 JSON 字符串存进去每次点赞要把整个字符串取出来、反序列化、修改、再序列化、写回去。而如果用 Redis 的Set类型一个SADD命令就搞定了而且天生去重。这就是数据类型的价值它把常见的数据结构和操作逻辑下沉到了服务端让客户端代码变得极其简洁同时性能还甩自定义方案几条街。所以搞懂 Redis 数据类型本质上是在搞懂 Redis 能替你干哪些活、怎么干最划算。1.2 从基础类型到扩展类型一张表看全先放一张全景表后面逐一拆解类型底层编码典型核心特征典型场景Stringint / embstr / raw二进制安全最基础缓存、计数器、分布式锁Hashziplistlistpack / hashtable字段级别的操作对象存储、商品信息Listquicklist双向链表 压缩列表消息队列、时间线Setintset / hashtable无序、去重、集合运算标签、共同关注、抽奖ZSetziplistlistpack / skiplistdict有序、可排序、带权重排行榜、延迟队列Bitmap基于 String 的位操作位级别操作省内存签到、在线状态、布隆过滤器HyperLogLog稀疏/稠密编码基数统计误差可控UV 统计Geo基于 ZSet 的编码地理位置计算附近的人、LBSStreamstream 结构消息队列可持久化消息中间件、事件流注意表格里的“底层编码”这个是理解 Redis 内存模型的关键后面专门开一节细讲。先把整体印象建立起来Redis 的数据类型不是孤立的概念每种类型都有精心设计的内部编码目的是在内存占用和操作效率之间找平衡。2. 踩坑最多的两个类型String 和 Hash 的深度拆解2.1 String 不只是存字符串三个隐藏用法先说 String。它是 Redis 最基础的类型也是绝大多数人用的第一个类型。表面上看就是存字符串但实际上 String 在 Redis 内部有三种编码方式int当 value 是整数时Redis 直接以整数形式存储不做字符串转换省内存且支持原子自增。embstr短字符串通常小于 44 字节内存连续分配读写快。raw长字符串需要两次内存分配但无长度限制。很多人不知道的是String 类型除了存文本还有三个高频用法计数器。INCR、DECR、INCRBY这些命令是原子操作底层就是int编码在起作用。我做秒杀系统的时候就用 Redis 的DECR做库存扣减单线程模型保证不会超卖。需要注意INCR操作如果 value 不是整数会返回错误所以不要把用户 ID 这种字符串硬当成计数器用。对象序列化存储。把 Java/Python 对象序列化成 JSON 或二进制然后存到 String 里。这里有个容易被忽略的问题Redis 的 String 是二进制安全的也就是说你存什么字节它就能原样吐出来什么字节。所以序列化框架随便选Jackson、Protobuf、Kryo都行。位图操作的载体。实际上 Bitmap 在底层就是一个 String只是按位来解释。后面单独说。用 String 的时候我建议养成一个习惯key 的命名要带业务前缀比如user:profile:1001、product:stock:8888。这是无数血泪教训换来的Redis 的 key 一旦多起来没有规范的命名排查问题能让你怀疑人生。2.2 Hash 比 String 强在哪字段级操作才是核心优势Hash 在 Redis 里的样子类似一个“小字典”一个 key 对应一个 field-value 集合。它最核心的价值是可以把对象的多个属性存在一个 key 下并且单独操作某个字段。举个例子。用户信息有昵称、头像、积分、等级四个字段。如果你用 String 存得序列化成一整条更新积分时要把整条取出来改完再写回去。如果用 HashHSET user:1001 nickname 老王 avatar /a.png points 1000 level 5 HINCRBY user:1001 points 100这种操作方式的优势有两个一是省带宽只传输变更的字段而不是整个序列化后的对象二是省 CPU不需要反序列化整个对象。我实测过缓存一个包含 20 个字段的对象Hash 的更新性能比 String 序列化方式能提升一个数量级当然前提是字段确实需要单独更新。Hash 有个典型的大坑需要提醒HGETALL慎用。如果这个 Hash 很大比如几万个字段HGETALL会把所有字段和值一次性返回网络 IO 直接拉满。建议用HSCAN分批获取或者设计时就把大 Hash 拆分。另外记住Redis 的 Hash 底层有两种编码字段少且值小时用listpack新版本替代了 ziplist一条连续内存省空间字段多了以后自动升级为hashtable空间换效率。这个升级是自动的不需要你干预但理解了能帮你解释“为什么我的 Hash 内存突然变大了”。2.3 序列化选择无论用什么框架都要记住“兼容性”三个字缓存场景逃不开序列化。Redis 客户端比如 Spring Data Redis默认的序列化器是 JDK 自带的存进去的东西是带类型描述的一长串字节肉眼不可读占空间还大。我见过生产环境 Redis 内存暴涨最后排查发现是默认 JDK 序列化搞的鬼。实践中的做法一般是JSON 序列化可读性好方便排查数据但空间开销略大没有类型信息。Protobuf 序列化体积小、速度快但二进制不可读排障要靠工具。Kryo / Hessian体积也小但要注意版本兼容性跨语言不友好。踩过几次坑之后我的原则是缓存数据用 JSON 序列化追求可读性队列消息用 Protobuf追求体积和性能。另外不管用哪种序列化一定要在序列化后的数据里带上版本标识或类型标识不然以后升级结构的时候老数据反序列化直接报错那场面相当酸爽。3. List、Set、ZSet集合操作的三种打开方式3.1 List不只是队列还能当栈和分页用List 在 Redis 里是双向链表支持头尾插入、弹出按下标取值等操作。它的内部编码是quicklist可以理解为“多个压缩块组成的链表”兼顾了内存紧凑和两端操作的效率。List 最常见的玩法是消息队列生产者LPUSH消费者BRPOP。BRPOP是阻塞式弹出队列为空时挂起等待避免了浪费 CPU 轮询。这个模式简单可靠很多小规模系统就直接用 Redis List 当消息队列用连 RabbitMQ 都省了。但 List 有个能力很多人忽略了分页查询。LRANGE key 0 9能取前 10 条配合LPUSH写入的新数据排在最前面天然适合做“最新动态列表”。我在一个社区项目里就用LPUSH LTRIM组合维护了一个定长的最新评论列表每条评论 push 进去后再LTRIM截断到最近 500 条内存控制得死死的。List 的坑主要在误用LINDEX。它是 O(N) 操作如果列表特别长按索引访问会非常慢。只要求按序访问头部尾部就用LPOP/RPOP千万别拿LINDEX当数组用。3.2 Set去重是表面集合运算才是灵魂Set 是无序不重复集合内部编码可能是intset全是整数且数量少时或hashtable。去重是它的基本功能SADD重复添加不会成功这个特性能干嘛做抽奖、做签到去重、做关注列表。但 Set 真正的价值在于集合运算SINTER交集求两个用户共同关注的博主。SUNION并集合并多个标签下的文章。SDIFF差集找出用户已关注但博主没回关的。这些运算命令在服务端直接完成客户端只要拿到结果就行。换成 MySQL 做同样的功能要么嵌套查询要么在应用层做 Set 交集代码复杂度和性能完全没法比。做推荐系统或者社交功能的时候Redis 的 Set 集合运算是非常趁手的武器。SMEMBERS命令需要注意它会把 Set 里的所有元素取出来如果集合非常大十万级别内存和带宽都会难受。建议改用SSCAN游标式遍历或者干脆别做全量取出的操作。3.3 ZSet 是有序的真相跳表 哈希的组合拳ZSet有序集合是 Redis 里最有“技术含量”的一个类型每个成员都关联一个分数score按分数排序。它的底层是skiplist dict的组合dict 保证 O(1) 的成员查找skiplist 保证分数排序和范围查询的高效性。这个设计让我想起小时候查字典的方法先翻到大概的页再逐页找。跳表就是一种多级索引链表可以快速跳过不需要遍历的节点。相比平衡树跳表的实现简单很多而且范围查询比如取分数段内的元素天然友好。ZSet 的经典应用场景排行榜。游戏玩家战力排行ZADD rank 5000 player_1然后用ZREVRANGE rank 0 9 WITHSCORES取前十名。分数更新也简单ZINCRBY rank 200 player_1直接加分自动重新排序。延迟队列。这个用法比较隐蔽但很实用把任务执行时间戳作为 score消费者轮询ZRANGEBYSCORE queue -inf now LIMIT 0 10拿到所有到期的任务执行执行完ZREM删掉。我拿它做过定时任务调度没有再引入额外的消息队列组件效果很好。ZSet 的坑是分数是浮点数精度有限。如果分数是整数千万以内的值没问题但超过2^53约 900 万亿就可能丢失精度。我在做积分排行时用的是“积分 * 1e6 时间戳偏移”的方式编码分数不用浮点而是整数运算避开了这个坑。4. 藏在进阶缝里的新类型Bitmap、HyperLogLog、Geo、Stream4.1 Bitmap用最小的内存干最大的事Bitmap 不是独立的数据类型它本质上是 String 类型上的位操作扩展。可以用SETBIT、GETBIT、BITCOUNT等命令按位操作。一个位就是一个 0/1 标记8 个位组成一个字节理论上存储 1 亿用户的签到状态只要约 12MB 内存。最典型的应用是签到系统和在线状态标记。一年 365 天给每个用户建一个 365 位的 BitmapSETBIT sign:2024:1001 0 1表示第 0 天签到了BITCOUNT sign:2024:1001统计用户年内签到天数。一行命令的事换成 MySQL 表存储光索引就够喝一壶的。但 Bitmap 的命令要注意位是从 0 开始编号的日常习惯的“第 1 天”要映射成“偏移量 0”这是最容易写错的地方。另外BITPOS命令可以快速找到第一个值为 0 或 1 的位我拿它做过“连续签到天数”的计算从今天往前找第一个未签到的位就知道连续签到了多少天。4.2 HyperLogLogUV 统计的作弊器如果你需要统计一个页面的 UV独立访客数传统做法是在数据库来一条记录或者用 Set 存用户 ID。数据量小没问题百万级 UV 的时候Set 内存就开始吃紧了。HyperLogLog 可以做到固定内存下统计海量基数无论存多少元素每个 key 最多占 12KB 内存标准误差在 0.81% 左右。用PFADD添加元素PFCOUNT统计基数。对一个日活千万的产品来说0.81% 的误差完全可接受省下的内存则是实打实的。有个点必须说清楚HyperLogLog 是“近似统计”不支持精准去重查询也不能反向枚举元素。如果你需要知道“具体哪些用户访问了”别用这个老老实实 Set 或落库。这是一个典型的“工具选型要看场景”的案例。4.3 Geo附近的人是怎么实现的Redis 3.2 开始提供了地理位置相关的类型GEO。它底层用的是 ZSet 结构只不过 score 是把经纬度通过 GeoHash 算法编码后得到的值。命令有GEOADD、GEODIST、GEOSEARCH等。实现“附近的人”功能GEOADD user_location 116.39 39.91 user_1添加用户位置。GEOSEARCH user_location BYLONLAT 116.39 39.91 BYRADIUS 5 km查询周边 5 公里的用户。底层 GeoHash 有个值得留意的特性它把地球划分为网格位置相近的点编码也相近但存在边界问题——两个其实很近的点可能落在相邻网格、编码距离却很远。所以严格来说GEOSEARCH是先筛候选集再算精确距离但边界点还是有罕见误差。对 LBS 这种“近似即可”的场景够用了。真正对精度要求苛刻的场景还是上 lucene 之类的专业引擎吧。4.4 Stream官方钦定的消息队列姿势Redis 5.0 引入了 Stream一个真正的、可持久化的消息队列模型弥补了之前 List 队列的不足。它支持消息 ID、消费者组Consumer Group、消息确认ACK和 Pending 机制语义上接近 Kafka但轻量得多。Stream 的完整机制展开讲能写一本书这里只说我实际项目中用到的核心流程XADD mq * field value往 stream 追加消息。XREADGROUP GROUP group1 consumer1 COUNT 10 BLOCK 2000 STREAMS mq 消费者组读取新消息。XACK mq group1 msg_id处理完后确认消息。相比 List 队列Stream 最大的提升是消费者组同一个消息可以被多个消费端分布式消费且不会被重复消费通过 ACK 机制保证。它还支持 XAUTOCLAIM 把超时未确认的消息重新投递给其他消费者解决“消费者宕机导致消息丢失”的老大难。5. 数据类型的底层实现与内存优化实践5.1 底层编码转换的规律前面提到过Redis 内部为每种数据类型设计了多种编码方式简单数据用小内存的紧凑结构大数据才升级为高级结构。这个“升级”机制非常值得理解因为它直接决定了你的内存开销。具体转换规则类型紧凑编码升级条件默认配置升级后编码Hashlistpack字段数 128 或单字段长度 64 字节hashtableZSetlistpack成员数 128 或 score 长度 64 字节skiplistSetintset元素全为整数且数量 512hashtableStringembstr长度 44 字节raw这里有个关键认知编码升级是不可逆的。一个 listpack 编码的 Hash 一旦升级为 hashtable即使后面删到字段数只剩 10 个也不会退回 listpack。这会导致一种情况你往一个 Hash 里临时塞了一大堆数据之后删除大部分内存却不会显著下降。生产环境维护 Redis 内存时如果发现某些 key 缩水后内存不见少往往就是这个原因。5.2 内存优化三板斧做完 Redis 内存优化的一个项目之后我总结出几条最实用的经验优先使用紧凑编码。写入 Hash 和 ZSet 时尽量控制单一 key 的大小让数据停留在 listpack 阶段。比如商品详情按“商品 ID 分段”存储不要让一个 Hash 膨胀到上万字段。合理配置 maxmemory-policy。内存打满时 Redis 的淘汰策略直接决定系统稳定性。allkeys-lru适合纯缓存volatile-ttl适合某些 key 要保活的场景。建议关闭noeviction否则写入会直接报错把缓存故障升级成业务故障。用 Redis 4.0 的 MEMORY 命令排查。MEMORY USAGE key能精确看到单个 key 占多少字节MEMORY STATS看全局分配情况。我经常在预发环境跑一遍全量 key 的MEMORY USAGE找出内存占用 top N优化效果立竿见影。还有个小技巧短 key 也占内存。Redis 的 key 本身也是字符串每一条都要存储并计算哈希。十万个 key 里的 key 名称每少一个字节总共就能省 100KB 左右。所以 key 命名在可读性和长度之间要平衡别写出user:profile:info:extra:detail:1001这种丧心病狂的长 key。6. 面试考点和实际项目中的经典坑6.1 缓存三大问题与数据类型的关系面试高频题“缓存穿透、缓存击穿、缓存雪崩”和数据类型的关系远比想象中大。缓存穿透查询一个不存在的 key请求直达数据库。解决思路是缓存空值用 String 存特殊标记或者用布隆过滤器。布隆过滤器可以基于 Bitmap 实现一个位数组加几个哈希函数就够了非常契合 Redis。如果数据量不大直接在 Redis 里用 Bitmap 手写一个也行命中判断的时候把误判率调低就行。缓存击穿热点 key 过期瞬间大量请求打爆数据库。解法是互斥锁而互斥锁要用到 Set 的SETNX或者SET NX EX组合实现。或者干脆逻辑过期——value 里存过期时间戳实际数据不设 TTL异步线程刷新缓存。这两种方案的实现都依赖数据类型属于典型的“类型选对方案做对”。缓存雪崩大量 key 同时过期数据库直接跪。预防措施是给过期时间加随机偏移量还有一个办法是热点 key 永不过期、用 ZSet 记录每个 key 的逻辑过期时间做异步续期。把 ZSet 当“定时任务表”用这里也是经典案例。6.2 分布式锁的正确打开方式分布式锁是 Redis 面试的常客也是工程里最容易出“看起来对实际有坑”的部分。最常见的错误版本是用SETNX加锁然后忘记释放或者释放错锁——在释放之前必须校验是不是自己的锁。正确做法一句话给锁的 value 设一个唯一标识释放锁时用 Lua 脚本校验并删除。而 Lua 脚本的原子性保障正是基于 Redis 单线程执行模型的。数据类型在这里的参与方式是锁本身只是一个 Redis String key但 setnx 的原子语义、ex 过期时间都是 String 类型命令范围内的能力。另外一个加分项是在代码里实现“可重入锁”——用 Hash 类型存锁的持有次数每次重入HINCRBY增计数释放时递减到 0 才真正删除。这是 Redisson 的实现思路面试时说出来是加分的。6.3 可视化客户端和运维排障的实用建议演进到运维视角很多人习惯装一个 Redis Desktop Manager 或者 Another Redis Desktop Manager 看数据。这类工具对看 String、List 没问题但对看 Hash 字段、ZSet 分数结构的时候建议关注官方 RedisInsight它对 Stream、Geo 这些高级类型的可视化做得更到位。排查线上问题时我建议按这个顺序来INFO memory看总内存和碎片率。MEMORY USAGE key定位大 key。SLOWLOG GET看慢命令重点揪出KEYS *这种全量扫描。开启慢日志的阈值建议设为 100ms 以下线上业务 10ms 以上的命令就得留意了。还有一个排障杀手锏Redis 6 以上推荐使用ACL给不同业务线创建不同权限的用户避免一个同事误操作FLUSHALL让整个集群数据蒸发。这个事故我亲眼见过一次恢复完成后全组人冒冷汗。6.4 序列化报错的经典场景Redis 使用中最多见的异常之一就是SerializationException。基本套路是数据写入时用一种序列化器读取时用了另一种结果反序列化失败。Spring Data Redis 环境下如果 RedisTemplate 的 key/value Serializer 配置不一致就会出现这种诡异问题。解决方案非常简单粗暴全局统一配置GenericJackson2JsonRedisSerializer并在序列化对象里带上class类型信息。存的时候有类型取的时候能精确还原。注意一点用 Jackson 序列化时不要用匿名内部类否则反序列化直接扑街。这个坑我踩过网上查了半小时才意识到类是匿名的、没有实际的类名可用。另外一个序列化的隐蔽坑是对象里加了新字段。线上老缓存数据没有新字段代码里新对象有非空校验反序列化时新字段为 null直接 NPE。所以缓存对象的结构变更要谨慎处理老数据——要么版本号隔离要么加默认值确保老数据兼容。实操总结选型时的三步决策法自己摸索了这么多年我总结出一个三步决策法每次设计 Redis 数据存储方案都直接套用第一步先想清楚数据的操作模式是读多写少还是写多读少是整体替换还是局部更新 第二步再明确数据结构的需求需要排序吗需要去重吗需要范围查询吗 第三步最后对照类型表选型局部更新选 Hash排序选 ZSet去重算交集选 Set位标记选 Bitmap近似基数统计选 HyperLogLog消息队列选 Stream。记住没有一种类型能通吃所有场景类型选错后面性能优化和代码重构都是加倍偿还。Redis 的学习曲线并不陡峭但数据类型的底层认知决定了你是在“用 Redis”还是只是“会用 Redis”。我个人把 Redis 数据类型当成一个工具箱来研究每次遇到新的存储业务先把五种基础类型过一遍再翻扩展类型思路清晰了很多。这篇文章里的每一个坑和经验都是真金白银买来的希望你在用 Redis 的路上能绕开我踩过的雷。