✅ String：字符串（最常用、最简单的类型）
📌 应用场景：
- 计数器
（如：页面浏览量、点赞数、转发数等）
- 缓存单个值
（如：token、验证码、用户昵称）
- 分布式锁
🔧 使用方式：
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：列表（有序，可重复）
📌 应用场景：
- 消息队列
（简单队列）
- 任务列表 / 待办事项
- 文章评论列表（按时间排序）
- 最近浏览记录
🔧 使用方式：
RPUSH task:pending task1
LPUSH comments:article:123 "这是一条评论"
LPOP task:pending
LRANGE task:pending 0 9🧠 原理：
底层使用 QuickList（压缩列表+双向链表的混合体）
插入和删除效率高，尤其适合两端操作
✅ 优点：
插入/读取非常快，适合队列结构
支持阻塞读写（BLPOP）
⚠️ 缺点与建议：
- 不支持多消费者分发消息
，同一条消息无法被多个消费者消费
更复杂的消息队列场景建议使用 Redis Stream
✅ Hash：哈希（类似 Java Map）
📌 应用场景：
- 购物车
（key = 用户，field = 商品ID，value = 数量）
- 缓存对象结构数据（用户信息、商品信息）
- 表单临时存储、会话信息等结构化数据
🔧 使用方式：
HSET cart:user:1001 10001 2
HSET user:1001 name "张三" age 18
HGETALL cart:user:1001🧠 原理：
少字段时用 ListPack（压缩结构） 节省内存
字段多或数据复杂时切换为 HashTable
✅ 优点：
适合结构化数据：一个 Key 下多个字段
节省内存，访问效率高
⚠️ 建议：
可结合 JSON 序列化在字段 value 存更多属性
使用时建议一个用户一个 key，方便管理和清理
✅ Set：集合（无序、唯一）
📌 应用场景：
- 点赞功能（去重）
- 标签系统（兴趣标签）
- 共同关注 / 好友关系运算
- 在线用户列表
🔧 使用方式：
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）：有序集合
📌 应用场景：
- 排行榜系统（根据分数排名）
- 延迟队列（score = 时间戳）
- 热门文章 / 热门话题
🔧 使用方式：
ZADD rank:game 200 user1001
ZADD rank:game 300 user1002
ZRANGE rank:game 0 -1 WITHSCORES
ZREVRANK rank:game user1001🧠 原理：
由 跳表（SkipList）+ 哈希表 构成
按照 score 排序插入，查询时效率高
✅ 优点：
能支持快速按 score 排序、范围查询
适合动态排行榜、分数管理、计时任务处理等
✅ BitMap：位图
📌 应用场景：
- 用户签到统计
- 用户是否登录、是否活跃
- 某个功能是否开启（布尔状态）
🔧 使用方式：
SETBIT sign:20250715 1001 1
GETBIT sign:20250715 1001
BITCOUNT sign:20250715🧠 原理：
本质是字符串，内部按位存储，1bit 表示一个状态
占用空间极小，适合高并发、大用户量场景
✅ 优点：
超省空间，100万用户只占约125KB
适合做大规模布尔值存储（状态标记）
✅ HyperLogLog：概率计数器
📌 应用场景：
- UV（独立用户访问数）统计
- 粗略的唯一元素去重计数
🔧 使用方式：
PFADD uv:20250715 user1001
PFCOUNT uv:20250715🧠 原理：
使用概率算法 HyperLogLog 估算基数
精度在 0.81% 左右，空间固定 12KB
✅ 优点：
超省内存，可统计上亿级唯一值
精度足以满足大多数运营分析需求
⚠️ 缺点：
- 不支持具体去重数据查看
（只能知道有多少，不知道是谁）
不适合对精度要求严格的计数
✅ GEO：地理位置
📌 应用场景：
- 查找附近的人/店
- 定位服务
- 地理范围筛选
🔧 使用方式：
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：消息队列（高级）
📌 应用场景：
- 异步消息处理（类似 Kafka）
- 订单流转、日志收集
- 多消费者消费模型
🔧 使用方式：
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 | 高级消息队列 | 多消费者、持久化 | 实时任务、日志 |
