Redis 8 大数据类型完整实战场景，看完不再只会 get/set
Redis 不是一个简单的 key-value 缓存。它有 8 种数据类型，每种类型都对应一套完整的业务场景。大多数人只会 SET 和 GET，等于开着法拉利在小区里遛弯。
今天把这 8 种类型的底层原理 + 实战场景一次性讲透。
一、String ------ 万能型选手，但别只当字符串用
底层结构：简单动态字符串（SDS），预分配冗余空间，内存连续，杜绝碎片。
别被名字骗了，value 可以存数字、JSON 甚至二进制。
🔥 实战场景
| 场景 | 命令 | 要点 |
|---|---|---|
| 缓存商品详情 | SET product:1001 '{"name":"手表","price":899}' EX 1800 |
EX 控制过期，防缓存雪崩 |
| 秒杀库存扣减 | SET inventory:sku NX + Lua 脚本 DECR |
NX 防重复初始化，Lua 保证原子性 |
| 分布式锁 | SET lock:task uuid123 NX EX 30 |
EX 自动释放防死锁，Lua 脚本安全删除 |
| 短信验证码 | SET sms:13800138000 884716 EX 60 + GETDEL |
GETDEL 保证一次性使用，防重复 |
| 当日操作计数 | SET user:1001:20260622_click 0 EX 86400 + INCR |
键名带日期自动归档，INCR 原子计数 |
| 错误次数限流 | INCR error:13800138000 EX 3600 |
独立计数器，每小时最多 5 次 |
关键认知 ：String 是原子操作最多的类型。INCR/DECR/GETSET 全部是单线程原子执行，高并发计数场景的首选。
性能提示：超过 10KB 的数据考虑拆分存储；数值型数据直接
SET key 42，Redis 会自动用 int 编码，比存字符串省 3 倍空间。
二、Hash ------ 存储对象的天然容器
底层结构：ziplist（元素少、值短时）+ hashtable（元素多时），自动切换。
Hash 的结构是 key → field → value，和对象的 id → 属性 → 值 完全同构。
🔥 实战场景
| 场景 | 命令 | 要点 |
|---|---|---|
| 缓存用户信息 | HSET user:1001 name "Alice" age 30 email "a@x.com" |
独立更新某个字段，无需读写整个对象 |
| 电商购物车 | HSET cart:1001 product:558 2 product:889 1 |
用户 ID 为 key，商品 ID 为 field，数量为 value |
| 文章互动计数 | HINCRBY article:998 likes 1 |
点赞/评论/分享聚合在一个 key 下 |
| 会话数据 | HSET session:abc token "xyz" expire 1700000000 |
比存 JSON 串省带宽，更新字段不用全量重写 |
核心优势：相比把整个对象序列化为 JSON 存 String，Hash 可以只修改一个字段，网络开销和并发冲突都大幅降低。
坑点：
HGETALL/HKEYS/HVALS在元素过多时会阻塞 Redis，生产环境请用HSCAN渐进式遍历。
三、List ------ 被低估的消息队列
底层结构：3.2 之前是双向链表，之后是 quicklist（ziplist + 链表节点），兼顾内存和性能。
🔥 实战场景
| 场景 | 命令 | 要点 |
|---|---|---|
| 消息队列（FIFO） | LPUSH queue:order msg + BRPOP queue:order 0 |
BRPOP 阻塞等待，避免空转轮询 |
| 最新 N 条记录 | LPUSH timeline:user1 post_id + LTRIM timeline:user1 0 99 |
只保留最新 100 条，自动淘汰旧数据 |
| 消息消费备份 | RPOPLPUSH queue:main queue:backup |
消费后自动备份，防消息丢失 |
关键认知：Redis 的 List 就是一个轻量级消息队列。虽然不如 RabbitMQ/Kafka 专业，但对于日志采集、异步通知、简单任务队列，性能足够且部署成本极低。
四、Set ------ 去重 + 集合运算的利器
底层结构：intset（全整数且 ≤512 个元素）+ hashtable。
Set 的杀手锏不是存数据，而是 集合运算：交集、并集、差集。
🔥 实战场景
| 场景 | 命令 | 要点 |
|---|---|---|
| 用户标签系统 | SADD user:1:tag "数码" "运动" |
自动去重，无需判断是否已存在 |
| 共同好友 | SINTER user:1:friends user:2:friends |
一条命令求交集，O(N) 复杂度 |
| 抽奖（随机抽） | SPOP lottery:20260622 1 |
随机弹出且自动删除，天然公平 |
| 推荐系统（共同兴趣） | SINTER tag1:users tag2:users |
找同时喜欢两个标签的用户 |
| 黑白名单 | SISMEMBER blacklist:ip "1.2.3.4" |
O(1) 判断是否在名单中 |
核心优势 ：SINTER/SUNION/SDIFF 三个命令，把原来需要多表 JOIN 的逻辑压缩成一条 Redis 命令，性能提升不是一个量级。
五、ZSet（有序集合）------ 排行榜的唯一答案
底层结构 ：跳表（skiplist）+ hashtable，ZADD 时间复杂度 O(log N)。
元素不重复，但每个元素关联一个 score，按分数排序。
🔥 实战场景
| 场景 | 命令 | 要点 |
|---|---|---|
| 商品销量榜 | ZADD rank:sales 1000 product:001 |
销量即 score，ZREVRANGE 取 Top N |
| 游戏排行榜 | ZADD rank:game 9527 player:abc |
分数可增减：ZINCRBY rank:game 10 player:abc |
| 延迟队列 | ZADD delay:queue 1719072000 "task_id" |
用时间戳作 score，ZRANGEBYSCORE 取出到期任务 |
| 热搜榜 | ZADD hotsearch:20260622 884716 "关键词" |
实时更新热度分数，ZREVRANGE 0 9 WITHSCORES |
高级选项（Redis 6.2+）：
ZADD key NX member score--- 只添加新成员ZADD key XX member score--- 只更新已有成员ZADD key GT member score--- 仅当新分数更高时才更新ZADD key LT member score--- 仅当新分数更低时才更新
这些选项让排行榜逻辑不再需要先查后写，一条命令搞定。
六、Geospatial ------ 地理位置计算
Redis 3.2 推出，底层用 zset 存储经纬度。
🔥 实战场景
| 场景 | 命令 | 要点 |
|---|---|---|
| 附近的人 | GEOADD cities:taiyuan 112.55 37.87 "user:001" |
经度在前，纬度在后 |
| 计算距离 | GEODIST cities:taiyuan user:001 user:002 m |
返回米数，底层是 Haversine 公式 |
| 附近商户 | GEORADIUS cities:taiyuan 112.55 37.87 5000 m |
5 公里范围内的所有点 |
适用范围：外卖、打车、社交附近的人。需要先下载城市数据，通过程序一次性导入。
七、HyperLogLog ------ 统计 UV 的神器
底层原理 ：基数统计算法，固定占用 12KB 内存，可统计 2^64 个不同元素。
🔥 实战场景
| 场景 | 对比 | 要点 |
|---|---|---|
| 网站 UV 统计 | PFADD uv:20260622 user_id |
传统用 Set 存所有 user_id，1 亿 UV 占用几 GB |
PFCOUNT uv:20260622 |
HyperLogLog 只要 12KB，误差仅 0.81% |
核心认知 ：HyperLogLog 的目的是计数，不是存储。它不保存具体数据，只告诉你"大概有多少个不同的人来过"。对于 UV、日活这类指标，它是最优解。
八、Bitmap ------ 位运算统治状态统计
底层结构：最小单位是 bit，每个 bit 只有 0 或 1。
🔥 实战场景
| 场景 | 命令 | 要点 |
|---|---|---|
| 用户签到统计 | SETBIT sign:202606 user_id 1 |
1 亿用户签到状态只需 ~12MB |
| 在线状态 | SETBIT online:20260622 user_id 1 |
BITCOUNT online:20260622 即时在线人数 |
| 每日活跃 | BITCOUNT active:20260622 |
一条命令统计 DAU |
| 用户行为分析 | SETBIT feature:a user_id 1 |
记录用户是否使用过某功能 |
核心优势 ：1 亿个用户的在线状态，用 String 存要 1 亿字节，用 Bitmap 只要 ~12MB。BITOP AND/OR/XOR 还能做用户群体交叉分析。
总结：一张表选对类型
| 数据类型 | 一句话定位 | 最佳场景 |
|---|---|---|
| String | 万能原子操作基座 | 缓存、计数、分布式锁、限流 |
| Hash | 对象存储专用容器 | 用户信息、购物车、会话 |
| List | 轻量级消息队列 | 最新列表、任务队列、日志 |
| Set | 去重 + 集合运算 | 标签、共同好友、抽奖 |
| ZSet | 按分数排序的集合 | 排行榜、延迟队列、热搜 |
| Geospatial | 地理位置计算 | 附近的人、周边商户 |
| HyperLogLog | 海量基数统计 | UV、DAU、独立访客 |
| Bitmap | 位级状态统计 | 签到、在线状态、行为分析 |
Redis 的 8 种数据类型，不是面试考点，是生产环境的武器库。选对类型，性能差的不是一点半点------是一个量级。