基于Redis Streams实现百万用户事件存储与实时推送方案咨询

一、消费组数量的实际限制 #

Redis本身没有硬性的消费组数量上限，真正的限制来自你的Redis实例的内存和性能：

• 每个消费组仅占用少量元数据内存（记录消费者、最后处理的消息ID等信息），1万个消费组的元数据加起来也就几MB，对普通Redis实例完全没压力。
• 但如果消费组规模涨到十万、百万级，元数据的内存占用才会逐渐显现，同时Redis处理大量消费组元数据读写时，性能会有明显下滑。

二、你当前方案的问题（每个用户一个Stream） #

给百万用户各建一个独立Stream，在生产环境会踩大雷：

• 百万个Stream对应百万个键，Redis的键空间会变得异常庞大，键遍历、内存回收这类操作都会变慢，甚至触发性能告警。
• 每个Stream的TTL要单独维护，要么写定时脚本逐个清理，要么手动配置，维护成本高到离谱。

三、更适合百万用户的优化方案 #

推荐单Stream+按用户分区+消费组绑定用户的模式，既省资源又好维护：

1. 单Stream存储所有用户事件：
   • 写入事件时，把user_id作为事件字段一起存入，用XADD写入时可加MAXLEN ~ 100000自动截断旧数据，再配合定时脚本用XTRIM按时间戳删除10分钟前的事件。
2. 消费组绑定单个用户：
   • 每个在线用户对应一个消费组，消费时执行命令：XREADGROUP GROUP <user_id> <client_id> STREAMS <stream_name> >，客户端在本地过滤出属于当前用户的事件（Redis Streams本身不支持服务端按字段过滤）。
   • 用户断开连接后，直接用XGROUP DESTROY删掉对应的消费组，避免无效元数据占用。
3. Vert.x客户端优化点：
   • 配置vertx-redis-client的连接池，合理设置最大连接数，减少Redis连接开销。
   • 批量处理Kafka消费到的事件，使用XADD的批量写入接口，提升写入效率。

四、1万个消费组的实际表现 #

如果你的场景暂时只有1万个消费组：

• 直接使用即可，Redis完全能扛住，不会有明显性能问题。
• 可以开启Redis的慢查询日志，监控XREADGROUP、XGROUP CREATE这类操作的延迟，确保在业务可接受范围内。

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