Redis Stream（消息流） · 1. 定位：解决什么问题
本文按 Redis 8.2.10 核对编码与配置默认值；命令的引入版本另行标注。生产配置可能不同，可通过 CONFIG GET 查询。示例面向独立实验服务，运行结果和内存数字未在本次实测。
Redis Stream（消息流）
本文按 Redis 8.2.10 核对编码与配置默认值；命令的引入版本另行标注。生产配置可能不同，可通过 CONFIG GET 查询。示例面向独立实验服务，运行结果和内存数字未在本次实测。
1. 定位：解决什么问题
Stream 是按条目 ID 组织的追加事件日志，提供游标读取和消费组。List 弹出后立即移除，Pub/Sub 不保留离线消息；需要事件重放、待确认状态与多个独立消费组时使用 Stream，但可靠性仍依赖持久化与消费流程。
基本操作示例
text
XADD learn:types:events * action login user 42
XRANGE learn:types:events - + COUNT 1XADD 返回自动生成的 ID，具体值随执行时间变化。消费组中的确认、待处理条目和故障后的接管需要配合设计；业务处理可能重复，仍需幂等性。应制定裁剪和保留策略，不能让事件无限增长。
参考：Stream。
比赛结果入库
生产者追加比赛结果，消费者通过消费组领取，在数据库提交结果后再 XACK。用比赛 ID 或事件 ID 在数据库建立唯一约束：如果提交成功、确认前进程崩溃，重新投递的事件不能重复发奖或重复结算。
消息 ID 在一条流内有序，不是跨所有流的全局业务 ID。消费组的待处理记录也不会自动保证处理进程恢复，需要检查超时消息并接管。规划裁剪时要考虑未处理消息，Redis 持久化与备份策略同样影响可恢复性。
聊天与事件广播
Pub/Sub 是发布订阅能力，不是一个键值数据类型，适合允许丢失的实时广播。离线订阅者无法靠它重放消息。Stream 可保存事件和消费位置，但同一消费组中的消费者通常分工处理；若每个独立业务都需要完整事件流，应分别管理消费组或读取游标。
继续阅读
- 数据与原子性
- 数据与原子性
- 完整实践