残酷的约翰2免安装绿色中文版
2.09G · 2025-09-20
Redis作为最流行的开源数据库之一，其在消息队列领域的应用经历了多个重要阶段。从早期的简单队列实现，到中间件方案的兴起，再到Redis自身功能的完善，每一步都体现了技术发展的轨迹。本文将从技术发展的角度，梳理Redis消息队列的演进历程，并探讨其在不同阶段的应用场景。
Redis最初并不是为消息队列专门设计的，但其内置的list数据结构为队列的实现提供了基础。早期的开发者们利用lpush和rpop命令模拟队列行为，构建了最简单的消息队列系统。
实现核心：Redis List基于双向链表（3.2版本前）或快速列表（QuickList，3.2+）
// Redis源码中的List结构定义
typedef struct list {
listNode *head; // 头节点
listNode *tail; // 尾节点
void *(*dup)(void *ptr); // 节点复制函数
void (*free)(void *ptr); // 节点释放函数
unsigned long len; // 链表长度
} list;
生产者： LPUSH/RPUSH 插入链表头/尾。 消费者： RPOP/LPOP 从链表尾/头取出。 阻塞操作： BRPOP/BLPOP 基于epoll实现事件循环等待。
# 生产者（终端1）
> LPUSH order_queue "{"order_id":1001}"
# 消费者（终端2）
> BRPOP order_queue 0 # 0表示无限等待
1) "order_queue"
2) "{"order_id":1001}"
这种用简单链表实现的消息队列首先有消息丢失的问题，比如消费者崩溃时消息未ACK，针对这个问题我们可以通过备份队列来优化。
核心结构：Redis使用pubsub_channels字典维护频道与订阅者的映射
// 源码中的频道结构
struct redisServer {
dict *pubsub_channels; // 频道字典
list *pubsub_patterns; // 模式匹配列表
};
// 订阅关系存储格式
"news.sports" -> [client1, client2, client3] # 频道直连订阅
"news.*" -> [client4, client5] # 模式匹配订阅
消息传递流程
发布订阅模式解决了List实现的痛点：单个消息可被多个消费者接收，基于事件驱动的即时通知（实时），并且能根据通配符订阅。
但是这种模式也是具有缺陷的，发布订阅模式的消息仅存储在订阅者连接中，不具有持有化的能力，所以网络闪断即丢失，并且离线客户端无法获取历史消息。
IoT设备群组：
PUBLISH device/group1/temperature "25.6℃"
实时性高，但是存在消息丢失的风险，在一些金融交易领域是不适用的。
消息存储结构：
typedef struct stream {
rax *rax; // 基数树存储消息
uint64_t length; // 消息总数
streamID last_id; // 最后一条消息ID
rax *cgroups; // 消费者组字典
} stream;
消息ID： <毫秒时间戳>-<序列号>（如 1651234567890-5）。 内容存储： 采用 Radix Tree 基数树，支持高效范围查询。
消费者组结构：
typedef struct streamCG {
streamID last_id; // 最后分发ID
rax *consumers; // 消费者列表
rax *pel; // 待确认消息列表(Pending Entries List)
} streamCG;
消息生命周期：
# *表示自动生成ID，也可自定义ID
XADD mystream * sensor_id 123 temp 36.5
底层操作： 生成全局递增ID，将消息存入Radix Tree，更新stream的last_id。
XGROUP CREATE mystream mygroup $ MKSTREAM
XREADGROUP GROUP mygroup consumer1 COUNT 1 BLOCK 2000 STREAMS mystream >
核心机制：> 表示只接收新消息，消息会同时加入PEL（Pending Entries List），每个消费者维护自己的未确认消息列表。
XACK mystream mygroup 1651234567890-0
从消费者组的PEL中移除，更新消费者游标。
# 设备上报
XADD sensor_data * device_id 123 temp 25.6
# 消费者组处理
XREADGROUP GROUP analytics consumer1 STREAMS sensor_data >
Redis Stream 通过精巧的数据结构设计，在保持Redis高性能特性的同时，提供了完整的消息队列能力。其核心优势在于采用了Radix Tree存储结构大大提高内存效率，单线程模型保证操作原子性还无需额外中间件。
适合需要消息持久化但又希望保持架构简洁的场景，是传统MQ与Redis List之间的完美平衡点。
工具的进化史就是需求的映射史
从List到Stream的演进，本质上是对不同时代业务需求的回应。理解每个阶段的设计取舍，才能在选择时做出最合适的架构决策。Redis的消息队列发展史，正是分布式系统演进的一个精彩切片。
