如何基于Redis Stream实现用户专属Web通知收件箱？

核心问题分析 #

为每个用户单独创建Redis Stream确实会在用户量激增时带来元数据管理压力——Redis需要维护大量Stream的结构信息，内存开销和管理成本都会上升，这个顾虑是合理的。下面给出两种更高效的替代方案，同时明确Hashmap的可行性。

方案一：分片式Stream架构 #

这是对原有Stream方案的优化，既保留Stream的时序特性，又大幅降低Stream数量：

• 分片规则：预先创建固定数量的Stream（比如100个，可根据用户规模调整），命名如notifications:shard:0、notifications:shard:1...notifications:shard:99
• 写入逻辑：生成通知时，对user_id做哈希取模（如hash(user_id) % 100），将消息写入对应分片的Stream。消息内容需包含：
  • user_id：用户唯一标识
  • type：通知类型（1-4）
  • deep_link：跳转链接
  • payload：渲染通知语的变量（如title、item_list）
  • created_at：时间戳（可选，Stream的消息ID本身带时间戳，也可直接用ID排序）
• 查询逻辑：根据用户ID取模找到对应分片Stream，用XREVRANGE（倒序，符合通知列表最新在前的习惯）按时间范围读取消息，在应用层过滤出当前用户的消息，最后根据type和payload渲染成最终通知语（如{title} - all success）
• 优势：Stream数量固定，Redis元数据开销可控；天然支持时序存储，无需额外排序；可结合消费者组实现异步通知推送等扩展功能

方案二：Sorted Set + Hash组合架构 #

利用Sorted Set的排序特性和Hash的高效存储能力，兼顾性能和内存效率：

• 存储结构：
  1. 用户通知索引：为每个用户创建一个Sorted Set，key为notifications:user:{user_id}，score设为通知的created_at时间戳，value为通知的唯一ID（如UUID）
  2. 通知详情存储：用一个全局Hash结构notification:details，field为通知ID，value为JSON格式的通知详情（包含type、deep_link、payload）
• 写入逻辑：先生成通知ID，将详情存入Hash，再把ID和时间戳加入对应用户的Sorted Set
• 查询逻辑：用ZREVRANGE获取用户的通知ID列表（按时间倒序），再用HMGET批量读取Hash中的详情，最后渲染通知语
• 优势：Sorted Set的排序查询性能极高；Hash批量读取效率好；相比每个用户一个Stream，Sorted Set的元数据开销更低；可通过ZREMRANGEBYScore快速删除旧通知

Hashmap的可行性分析 #

单独使用Hashmap完全不可行：

• Hashmap仅支持键值对存储，无法直接按时间排序查询，要获取用户的时序通知列表，必须遍历该用户Hash下的所有键值对，再在应用层排序，性能极差，完全不符合你的需求
• 即使额外维护排序信息，也会引入复杂的同步逻辑，反而不如上述方案高效

额外优化建议 #

• 旧通知归档：将超过30天（或自定义周期）的通知迁移到RDB或对象存储，Redis仅保留最近的活跃通知，减少内存占用
• 消息压缩：对通知的payload进行JSON压缩或只存储必要变量，降低Redis内存消耗
• 批量操作：查询时优先使用批量命令（如HMGET、XREVRANGE的范围查询），减少与Redis的交互次数

内容的提问来源于stack exchange，提问作者chocho