Redis都有哪些数据结构，使用场景与原理解析

✅ String：字符串（最常用、最简单的类型）

📌 应用场景：

1. 计数器

   （如：页面浏览量、点赞数、转发数等）

2. 缓存单个值

   （如：token、验证码、用户昵称）

3. 分布式锁

🔧 使用方式：

SET user:1001 "张三"
SET token:abcd1234 "user1001"
INCR page:views
SET lock:order123 1 NX EX 30

🧠 原理：

• 底层是 SDS（Simple Dynamic String）简单动态字符串

• 是 Redis 自定义的字符串类型，支持动态扩容、安全、长度记录

✅ 优点：

• 使用简单，几乎所有业务都可以上手

• 支持数值加减操作，适合做计数器

• 原子性强，适合做分布式锁

⚠️ 缺点与建议：

• 分布式锁建议用 Redisson、RedLock 来避免失效风险

• 不适合存储结构化数据（比如对象或数组）

---

✅ List：列表（有序，可重复）

📌 应用场景：

1. 消息队列

   （简单队列）

2. 任务列表 / 待办事项
3. 文章评论列表（按时间排序）
4. 最近浏览记录

🔧 使用方式：

RPUSH task:pending task1
LPUSH comments:article:123 "这是一条评论"
LPOP task:pending
LRANGE task:pending 0 9

🧠 原理：

• 底层使用 QuickList（压缩列表+双向链表的混合体）

• 插入和删除效率高，尤其适合两端操作

✅ 优点：

• 插入/读取非常快，适合队列结构

• 支持阻塞读写（BLPOP）

⚠️ 缺点与建议：

• 不支持多消费者分发消息

  ，同一条消息无法被多个消费者消费

• 更复杂的消息队列场景建议使用 Redis Stream

---

✅ Hash：哈希（类似 Java Map）

📌 应用场景：

1. 购物车

   （key = 用户，field = 商品ID，value = 数量）

2. 缓存对象结构数据（用户信息、商品信息）
3. 表单临时存储、会话信息等结构化数据

🔧 使用方式：

HSET cart:user:1001 10001 2
HSET user:1001 name "张三" age 18
HGETALL cart:user:1001

🧠 原理：

• 少字段时用 ListPack（压缩结构） 节省内存

• 字段多或数据复杂时切换为 HashTable

✅ 优点：

• 适合结构化数据：一个 Key 下多个字段

• 节省内存，访问效率高

⚠️ 建议：

• 可结合 JSON 序列化在字段 value 存更多属性

• 使用时建议一个用户一个 key，方便管理和清理

---

✅ Set：集合（无序、唯一）

📌 应用场景：

1. 点赞功能（去重）
2. 标签系统（兴趣标签）
3. 共同关注 / 好友关系运算
4. 在线用户列表

🔧 使用方式：

SADD like:article:123 user1001
SREM like:article:123 user1001
SISMEMBER like:article:123 user1001
SCARD like:article:123
SINTER user:1001:friends user:1002:friends

🧠 原理：

• 底层是哈希表结构，插入/查找都是 O(1)

• 元素唯一，自动去重

• 支持交集、并集、差集等集合运算

✅ 优点：

• 非常适合“去重”场景

• 集合运算支持高级分析（如共同点赞、共同好友）

⚠️ 建议：

• 不能存重复数据，若需要统计次数，用 Hash 或 ZSet 替代

---

✅ ZSet（Sorted Set）：有序集合

📌 应用场景：

1. 排行榜系统（根据分数排名）
2. 延迟队列（score = 时间戳）
3. 热门文章 / 热门话题

🔧 使用方式：

ZADD rank:game 200 user1001
ZADD rank:game 300 user1002
ZRANGE rank:game 0 -1 WITHSCORES
ZREVRANK rank:game user1001

🧠 原理：

• 由 跳表（SkipList）+ 哈希表 构成

• 按照 score 排序插入，查询时效率高

✅ 优点：

• 能支持快速按 score 排序、范围查询

• 适合动态排行榜、分数管理、计时任务处理等

---

✅ BitMap：位图

📌 应用场景：

1. 用户签到统计
2. 用户是否登录、是否活跃
3. 某个功能是否开启（布尔状态）

🔧 使用方式：

SETBIT sign:20250715 1001 1
GETBIT sign:20250715 1001
BITCOUNT sign:20250715

🧠 原理：

• 本质是字符串，内部按位存储，1bit 表示一个状态

• 占用空间极小，适合高并发、大用户量场景

✅ 优点：

• 超省空间，100万用户只占约125KB

• 适合做大规模布尔值存储（状态标记）

---

✅ HyperLogLog：概率计数器

📌 应用场景：

1. UV（独立用户访问数）统计
2. 粗略的唯一元素去重计数

🔧 使用方式：

PFADD uv:20250715 user1001
PFCOUNT uv:20250715

🧠 原理：

• 使用概率算法 HyperLogLog 估算基数

• 精度在 0.81% 左右，空间固定 12KB

✅ 优点：

• 超省内存，可统计上亿级唯一值

• 精度足以满足大多数运营分析需求

⚠️ 缺点：

• 不支持具体去重数据查看

  （只能知道有多少，不知道是谁）

• 不适合对精度要求严格的计数

---

✅ GEO：地理位置

📌 应用场景：

1. 查找附近的人/店
2. 定位服务
3. 地理范围筛选

🔧 使用方式：

GEOADD store:city 120.38 36.06 store1
GEORADIUS store:city 120.38 36.06 5 km
GEODIST store:city store1 store2 km

🧠 原理：

• Redis GEO 底层使用 ZSet，score 是地理位置转为整数 score 的编码值

• 查询时转换为范围查询

✅ 优点：

• 精度高、效率快

• 查询方便，结合 ZSet 进行范围定位

---

✅ Stream：消息队列（高级）

📌 应用场景：

1. 异步消息处理（类似 Kafka）
2. 订单流转、日志收集
3. 多消费者消费模型

🔧 使用方式：

XADD order:stream * orderId 123 status created
XREAD COUNT 1 STREAMS order:stream 0
XGROUP CREATE order:stream group1 $
XREADGROUP GROUP group1 consumer1 STREAMS order:stream >

🧠 原理：

• 内部使用 RadixTree + ListPack 高效存储

• 每条消息是一个有序条目（ID 唯一），支持消费确认

• 支持消费者组，保证“每个消息分发给一个消费者”

✅ 优点：

• 支持持久化、多消费者、消息确认

• 是 Redis 中真正的消息队列结构，功能完善

⚠️ 建议：

• 替代 List 做消息队列

• 对性能和可靠性要求高时优选

---

✅ 整体对比表（一句话总结）

数据结构	应用场景	特点	适用关键词
String	单值缓存、计数、锁	简单高效	计数器、token、验证码
Hash	对象、购物车	结构化、节省空间	多字段数据
List	队列、评论	有序、支持阻塞	先进先出、任务队列
Set	点赞、关注	唯一、支持集合运算	去重、关系运算
ZSet	排行榜、延迟队列	有序、按分数排序	热门排序
BitMap	签到、状态	位运算、极省空间	用户标记
HyperLogLog	UV统计	概率估算	大规模去重
GEO	附近的人	经纬度范围查询	LBS服务
Stream	高级消息队列	多消费者、持久化	实时任务、日志