Redis 8 大数据类型完整实战场景

Redis 8 大数据类型完整实战场景，看完不再只会 get/set

Redis 不是一个简单的 key-value 缓存。它有 8 种数据类型，每种类型都对应一套完整的业务场景。大多数人只会SET和GET，等于开着法拉利在小区里遛弯。

今天把这 8 种类型的底层原理 + 实战场景一次性讲透。

一、String —— 万能型选手，但别只当字符串用

底层结构：简单动态字符串（SDS），预分配冗余空间，内存连续，杜绝碎片。

别被名字骗了，value 可以存数字、JSON 甚至二进制。

🔥 实战场景

关键认知：String 是原子操作最多的类型。INCR/DECR/GETSET全部是单线程原子执行，高并发计数场景的首选。

性能提示：超过 10KB 的数据考虑拆分存储；数值型数据直接SET key 42，Redis 会自动用 int 编码，比存字符串省 3 倍空间。

二、Hash —— 存储对象的天然容器

底层结构：ziplist（元素少、值短时）+ hashtable（元素多时），自动切换。

Hash的结构是key → field → value，和对象的id → 属性 → 值完全同构。

🔥 实战场景

核心优势：相比把整个对象序列化为 JSON 存 String，Hash 可以只修改一个字段，网络开销和并发冲突都大幅降低。

坑点：HGETALL/HKEYS/HVALS在元素过多时会阻塞 Redis，生产环境请用HSCAN渐进式遍历。

三、List —— 被低估的消息队列

底层结构：3.2 之前是双向链表，之后是 quicklist（ziplist + 链表节点），兼顾内存和性能。

🔥 实战场景

关键认知：Redis 的 List 就是一个轻量级消息队列。虽然不如 RabbitMQ/Kafka 专业，但对于日志采集、异步通知、简单任务队列，性能足够且部署成本极低。

四、Set —— 去重 + 集合运算的利器

底层结构：intset（全整数且 ≤512 个元素）+ hashtable。

Set 的杀手锏不是存数据，而是集合运算：交集、并集、差集。

🔥 实战场景

核心优势：SINTER/SUNION/SDIFF三个命令，把原来需要多表 JOIN 的逻辑压缩成一条 Redis 命令，性能提升不是一个量级。

五、ZSet（有序集合）—— 排行榜的唯一答案

底层结构：跳表（skiplist）+ hashtable，ZADD时间复杂度 O(log N)。

元素不重复，但每个元素关联一个score，按分数排序。

🔥 实战场景

高级选项（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 存储经纬度。

🔥 实战场景

适用范围：外卖、打车、社交附近的人。需要先下载城市数据，通过程序一次性导入。

七、HyperLogLog —— 统计 UV 的神器

底层原理：基数统计算法，固定占用12KB内存，可统计 2^64 个不同元素。

🔥 实战场景

核心认知：HyperLogLog 的目的是计数，不是存储。它不保存具体数据，只告诉你"大概有多少个不同的人来过"。对于 UV、日活这类指标，它是最优解。

八、Bitmap —— 位运算统治状态统计

底层结构：最小单位是 bit，每个 bit 只有 0 或 1。

🔥 实战场景

核心优势：1 亿个用户的在线状态，用 String 存要 1 亿字节，用 Bitmap 只要 ~12MB。BITOP AND/OR/XOR还能做用户群体交叉分析。

总结：一张表选对类型

Redis 的 8 种数据类型，不是面试考点，是生产环境的武器库。选对类型，性能差的不是一点半点——是一个量级。