2. Redis核心数据结构回顾：String、List、Set、Sorted Set、Hash的使用场景与性能对比

在构建基于Redis的消息队列与热Key分析系统之前，必须深入理解五种核心数据结构的底层特性。不同的数据结构在内存占用、读写时间复杂度、并发安全性和功能边界上存在显著差异，选型错误将直接导致消息丢失、延迟飙升或资源浪费。

2.1 数据结构全景对比

下表从底层编码、时间复杂度、消息队列适配度三个维度进行横向对比，帮助快速建立选型框架。

2.2 各数据结构深度解析

2.2.1 String — 最轻量的原子操作单元

String 是 Redis 最基础的数据类型，最大 512MB。在消息队列中，String 通常不直接存储消息体，而是承担 计数器、分布式锁 和 去重标记 的角色。

• INCR / DECR： 原子自增，用于生成全局唯一的消息ID或消费次数统计。
• SETNX： 实现分布式锁，防止重复消费。
• SETEX： 带过期时间的去重标记，适合时间窗口去重。

// 使用 String 实现消息去重标记（TTL 窗口）
SET task:dedup:order_12345 "processed" EX 3600 NX
// 返回 OK 表示首次处理，返回 nil 表示重复消息

2.2.2 List — 阻塞队列的基石

List 基于 quicklist 实现，结合了 ziplist 的紧凑性和 linkedlist 的插入效率。LPUSH + BRPOP 组合是 Redis 消息队列最经典的实现模式。

• LPUSH / RPUSH： 生产者向队列头部或尾部插入消息。
• BRPOP / BLPOP： 消费者阻塞等待消息，支持超时和多个队列优先级。
• LLEN： 监控队列积压长度，触发告警。

// 生产者
LPUSH task:queue "{\"id\":1001,\"type\":\"email\"}"

// 消费者（阻塞等待，超时 30 秒）
BRPOP task:queue 30

2.2.3 Set — 天然的去重容器

Set 基于 hashtable 或 intset 实现，所有元素唯一。在消息队列中，Set 主要用于 已消费消息ID集合 和 任务白名单。

• SADD： 添加消息ID，返回 1 表示首次添加，0 表示已存在。
• SISMEMBER： O(1) 判断消息是否已处理。
• SCARD： 统计去重集合大小，用于监控。

// 使用 Set 做消息去重
SADD consumed:messages "msg_20250321_001"
// 返回 1 表示成功去重，返回 0 表示重复消息

2.2.4 Sorted Set — 延迟队列与时间窗口的核心

Sorted Set 使用 skiplist + dict 实现，每个元素关联一个 double 类型的 score。在消息队列中，score 通常存储 时间戳 或 优先级权重。

• ZADD： 添加消息，score 为执行时间戳。
• ZRANGEBYSCORE： 获取到期的消息。
• ZREM： 消费后移除消息。
• ZCOUNT： 统计时间窗口内的消息数量，用于热Key检测。

// 延迟队列：score = 执行时间戳
ZADD delay:queue 1711000000 "task_001"
ZADD delay:queue 1711003600 "task_002"

// 消费者轮询获取到期任务
ZRANGEBYSCORE delay:queue -inf 1711000000
// 返回 ["task_001"]

2.2.5 Hash — 消息元数据的结构化存储

Hash 适合存储消息的多个字段，如消息体、重试次数、创建时间、消费者标识等。相比将整个消息序列化为 String，Hash 支持 部分字段更新，减少网络传输。

• HSET / HGET： 单字段读写，O(1)。
• HINCRBY： 原子递增重试次数。
• HDEL： 删除特定字段。

// 存储消息元数据
HSET task:meta:1001 body "{\"order\":\"12345\"}" retry 0 status "pending"

// 原子递增重试次数
HINCRBY task:meta:1001 retry 1

2.3 性能对比与选型决策树

以下 SVG 图展示了五种数据结构在消息队列场景下的性能特征对比，帮助快速定位最适合当前场景的数据结构。

2.4 消息队列场景下的数据结构组合策略

单一数据结构往往无法满足复杂消息队列的需求。实际生产环境中，通常采用 组合策略 来平衡性能与功能。以下 SVG 图展示了一个典型的组合架构。

2.5 常见选型误区与避坑指南