今天系统学习了 Redis 中的 List、Pub/Sub、Stream 三种与消息、队列相关的功能，在实际业务里这三者经常被混淆使用，导致出现消息丢失、消费异常、维护困难等问题。本篇从实战出发，清晰梳理三者的核心原理、使用方式、适用场景以及工程上的边界和避坑要点，做到用法明确、选型有据、落地稳妥。
一、List基础用法与特点
Redis List 是基于双向链表实现的有序列表结构，支持从两端快速插入和弹出数据，操作简单、性能稳定。
常用命令以队列模式为例：
左侧写入数据：LPUSH
右侧读取数据：RPOP
阻塞式读取：BRPOP，避免空轮询消耗资源
截取列表长度：LTRIM，可控制列表最大容量
List 的优势是使用简单、延迟低，适合作为轻量列表或临时队列。但它没有消息确认机制，数据一旦被弹出就会从列表中移除，无法重新消费，也不支持多消费者组和消息堆积追溯。
在实际项目中，List 适合用来缓存最新消息列表、排行榜片段、简单的临时任务队列等对数据可靠性要求不高的场景。
需要特别注意的是，不建议用 List 处理核心业务消息，一旦消费者处理失败，消息无法找回，容易造成业务数据丢失。
二、Redis Pub/Sub 发布订阅模式解析
Pub/Sub 是 Redis 内置的发布订阅模型，生产者向指定频道发送消息，订阅该频道的所有消费者都能同时收到消息，实现一对多的消息分发。
核心操作包括：
发布消息：PUBLISH
订阅频道：SUBSCRIBE
模式匹配订阅：PSUBSCRIBE
Pub/Sub 的特点是实时性强、推送速度快，适合多实例广播通知。但它不会持久化保存消息，消费者离线期间的消息会直接丢失，也没有消息确认、重试、堆积等能力。
工程中适合用在实时状态同步、前端消息提示、配置刷新广播等允许消息丢失的场景。对于订单、支付、日志留存等关键业务，Pub/Sub 无法保证消息可靠性，不建议使用。
三、Redis Stream 可靠消息队列详解
Redis Stream 是专门为消息队列设计的数据结构，具备完整的消息持久化、消费组、消息确认、回溯消费等能力，是生产环境中可靠消息的首选方案。
核心功能与命令：
写入消息：XADD，自动生成唯一消息 ID
创建消费组：XGROUP，实现多消费者负载均衡
分组消费：XREADGROUP，支持阻塞等待
消息确认：XACK，避免消息重复消费
查看待处理消息：XPENDING，用于处理消费失败任务
Stream 会持久化保存消息，支持历史消息查询，配合消费组和 ACK 机制，可以保证消息至少被消费一次，适合异步任务、订单通知、日志收集、微服务事件传递等对可靠性有要求的业务。
使用时需要注意合理设置消息长度，定期清理过期数据，避免无限堆积占用内存，同时及时确认消息，防止待处理列表膨胀。
四、三者核心差异与工程选型边界
从实际开发角度对比，可以更清晰地划分使用边界：
List 偏向列表结构，轻量简单，无持久化消费，适合非关键临时队列。
Pub/Sub 偏向实时广播，不存消息、不保证可靠，适合一对多通知场景。
Stream 偏向企业级消息队列，支持持久化、消费组、ACK，适合核心业务消息流转。
在工程实践中，应遵循明确的选型规则：
对可靠性无要求、简单临时任务→使用 List
实时多播、允许消息丢失→使用 Pub/Sub
核心业务、需要不丢消息、可重试→使用 Stream
五、实战避坑与规范总结
不要用 List 实现核心业务消息队列，避免消息丢失无法追溯。
不要用 Pub/Sub 处理支付、订单等重要消息，离线期间消息会直接丢失。
使用 Stream 必须搭配消费组和 ACK 机制，否则会出现重复消费。
三种功能各司其职，不混用、不乱用，保证代码逻辑清晰、易于维护。
对消息量较大的场景，及时设置数据淘汰策略，防止 Redis 内存溢出。
总体来说，List、Pub/Sub、Stream 各有适用范围，理解其底层原理和工程边界，才能在实际项目中做出合理选择，写出稳定、可靠、易于维护的代码。
