Redis支持哪些数据类型？各适用于什么场景？

Redis（C语言实现）支持以下9种核心数据类型及其适用场景：

• String（字符串）
  
  
  
  • 场景：缓存、计数器、分布式锁
    
  • 示例：SET user:1001 "John" EX 60（缓存用户信息60秒）
    
  • 上风：二进制安全，最大支持512MB （不会用UTF8解释器去解析内容，不感知内容，也不破坏内容）
    
  • 存储布局：简朴动态字符串（SDS）(雷同于c++的std::string，不须要管理内存，C的默认须要管理内存)
    
  • 快速查找：直接通过key定位，时间复杂度O(1) （hash表存储key和value的指针对象）
    
  • 布局特点：预分配冗余空间淘汰内存重分配（额外分配了内存，字串增长的时间不消额外分配内存）
    这些优化大部分是因为C语言特性而须要额外优化。
    
  
  
• Hash（哈希表）
  
  
  
  • 场景：存储对象属性、购物车数据
    
  • 示例：HMSET product:1001 name "hone" price 599 stock 50
    HMSET product:1001 name “Phone” price 599 stock 50这条下令的意思是，在Redis数据库中为一个名为product:1001的key设置了一个hash布局的数据，这个hash布局中包罗了三个字段（field）：name、price和stock，它们对应的值（value）分别是"hone"、599和50。
    
  • 上风：字段级原子操纵，节流网络流量
    原子：单下令操纵或Lua脚本，节流：按需取hash布局的返回内容，如果是string存json，须要返回全部json
    
  • 存储布局：ziplist（元素≤512）或hashtable
    
  • 快速查找：hashtable实现O(1)字段访问
    
  
  
• List（列表）
  
  
  
  • 场景：消息队列、最新消息列表
    
  • 示例：LPUSH news "Breaking: Redis 7 released"
    这条下令的意思是将字符串"Breaking: Redis 7 released"插入到名为news的列表的左端。
    
  • 上风：支持双向操纵和阻塞弹出
    
  • 存储布局：quicklist（ziplist链表）
    
  • 快速查找：索引访问O(n)，头尾操纵O(1)
    
  
  
• Set（集合）
  
  
  
  • 场景：标签体系、共同挚友
    
  • 示例：SADD article:1234 tags "tech" "database"
    这行给出了一个Redis下令的示例。SADD是Redis中用于向集合添加元素的下令。在这个例子中，article:1234是集合的键（key），tags是这个键对应的集合的名称（虽然这里看起来像是键的一部分，但在现实操纵中，我们通常会将集合的名称作为键的一部分来区分差别的集合）。"tech"和"database"是要添加到集合中的两个元素。执行这条下令后，"tech"和"database"这两个字符串就会被添加到名为article🔢tags（假设这里的tags是集合名称的一部分，现实下令中可能须要明确指定完备的集合键名）的集合中。
    
  • 上风：集合运算本领（交并差）
    
  • 存储布局：intset（纯整数）或hashtable
    
  • 快速查找：hashtable实现O(1)存在检测
    
  
  

5. Sorted Set（有序集合）

• ‌场景‌：排行榜、范围查询
  Sorted Set非常适合用于实现排行榜功能，因为元素会根据分数主动排序。同时，它也支持范围查询，可以方便地获取指定分数范围内的元素。
  
• 示例‌：ZADD leaderboard 3500 “playerA” 2800 “playerB”
  这条下令向名为leaderboard的Sorted Set中添加了两个元素，playerA的分数为3500，playerB的分数为2800。
  
• 上风‌：主动排序+范围查询
  Sorted Set的最大上风在于它能够主动根据分数对元素举行排序，而且支持高效的范围查询。
  
• 存储布局‌：跳跃表+哈希表组合
  Sorted Set的底层存储布局结合了跳跃表和哈希表。跳跃表用于维护元素的排序次序，而哈希表则用于快速查找元素的分数。
  
• 快速查找‌：score范围查询O(logN)，member查score O(1)
  在Sorted Set中，举行分数范围查询的时间复杂度为O(logN)，而根据元素查找其分数的时间复杂度为O(1)。
  

6. Bitmaps（位图）

• ‌场景‌：用户在线状态、特性标记
  Bitmaps非常适合用于表示大量的布尔值数据，如用户的在线状态或某些特性的标记。
  
• ‌示例‌：SETBIT online_users 1001 1
  这条下令将online_users位图的第1001位设置为1，通常用于表示某个用户（如用户ID为1001）的在线状态。
  
• ‌上风‌：极端内存优化（1bit/标记）
  Bitmaps的最大上风在于其内存使用效率极高，每个标记只占用1bit。
  

‌存储布局‌：String类型扩展
在Redis中，Bitmaps现实上是基于String类型举行扩展实现的。

• ‌快速查找‌：位运算O(1)
  由于位运算的高效性，Bitmaps中的查找操纵可以在O(1)时间复杂度内完成。
  

7. HyperLogLog

• ‌场景‌：UV统计
  HyperLogLog是一种用于估算大数据集基数的概率算法，非常适合用于UV（独立访客）统计等场景。
  
• ‌示例‌：PFADD visitors 192.168.1.1 192.168.1.2
  这条下令向名为visitors的HyperLogLog中添加了两个元素（通常是用户的IP地址）。
  
• ‌上风‌：固定12KB存储任意基数
  HyperLogLog算法的最大上风在于其内存使用非常固定，无论数据集的大小如何，都只须要12KB的内存空间。
  
• ‌存储布局‌：密集寄存器数组
  HyperLogLog的底层存储布局是基于密集寄存器数组实现的。
  
• ‌快速查找‌：仅支持基数估算
  须要注意的是，HyperLogLog只支持基数的估算，而不支持精确计算。其查找操纵现实上是估算操纵，时间复杂度较低。
  

8. Geospatial（地理空间）

• ‌场景‌：附近的人
  Geospatial数据类型非常适合用于实现“附近的人”等基于地理位置的查询功能。
  
• ‌示例‌：GEOADD cities 116.397128 39.916527 “Beijing”
  这条下令向名为cities的地理空间数据会合添加了一个地理位置，经度为116.397128，纬度为39.916527，标记为"Beijing"。
  
• ‌上风‌：GeoHash编码优化
  Geospatial数据类型使用了GeoHash编码对地理位置举行编码和优化，提高了查询效率。
  
• ‌存储布局‌：Sorted Set扩展
  在Redis中，Geospatial数据类型现实上是基于Sorted Set举行扩展实现的。
  
• ‌快速查找‌：GEORADIUS使用跳表O(logN)
  使用GEORADIUS下令举行地理位置范围查询时，其时间复杂度为O(logN)，因为底层使用了跳表布局举行优化。
  

9. Stream（流）

• 场景‌：消息长期化
  Stream数据类型非常适合用于实现消息队列和消息长期化功能。
  

‌ - 示例‌：XADD orders * productID 1001 userID 5566
这条下令向名为orders的Stream中添加了一条消息，消息ID由Redis主动生成（*表示），消息体包罗productID和userID两个字段。

• ‌上风‌：支持消费者组和ACK机制
  Stream数据类型的最大上风在于其支持消费者组和ACK（确认）机制，可以方便地实现消息的分发和消费确认。
  
• ‌存储布局‌：基数树（Rax）
  在Redis中，Stream数据类型的底层存储布局是基于基数树（Rax）实现的。
  
• ‌快速查找‌：ID范围查询O(logN)
  使用Stream数据类型举行ID范围查询时，其时间复杂度为O(logN)，因为底层使用了高效的数据布局举行优化。
  

计划哲学与限定原因：

• 性能优先：全部操纵时间复杂度控制在O(1)或O(logN)
  
• 内存效率：接纳特殊编码（ziplist/intset等）优化存储
  
• 组合本领：通过类型组合实现复杂布局（如用ZSET+Hash实现二级排序）
  
• 长期化需求：包管RDB快照的高效序列化
  
• 网络协议：RESP协议对底子类型的原生支持
  

扩展方式：

• 模块化架构（Redis Modules）可添加新数据类型
  
• 使用Lua脚本组合现有类型实现复杂逻辑
  
• 通过RedisJSON、RedisGraph等模块扩展功能