多用户连接场景下RabbitMQ应用及文件传输监控可扩展方案问询

核心问题拆解与解决方案 #

• WebSocket资源顾虑消除：1000个WebSocket连接完全在现代服务器的承载范围内。以Go或Node.js为例，单实例轻松支撑数万连接，每个连接仅占用几KB到几十KB内存，1核2G配置的服务器就能轻松应对。建议用集群部署WebSocket服务，搭配Nginx做负载均衡，同时设置心跳机制维持连接，避免无效占用。
• RabbitMQ的正确用法：绝对不能直接暴露RabbitMQ给终端用户——这会带来消息篡改、非法订阅等安全风险，且客户端集成成本极高。正确流程是：所有者发送请求后，服务器将消息投递到RabbitMQ的用户专属队列；用户端通过WebSocket连接到服务器，服务器从对应队列拉取消息后推送给用户。这样既利用了RabbitMQ的消息持久化、可靠路由能力，又隔绝了终端与MQ的直接接触，保障安全。
• FCM兜底方案：当WebSocket连接中断时，降级为「客户端定时轮询+本地弹窗通知」。客户端每隔30秒请求服务器查询未处理请求，一旦检测到就触发本地弹窗（只要应用进程存活，无论前后台都能触发），弥补FCM的局限性。

替代独立Checker的分布式实现 #

• Redis Stream + 消费者组模型：彻底抛弃每个用户一个Checker的方案，改用Redis Stream构建事件驱动的监控体系：
  1. 客户端每上传一个文件，就向Redis Stream写入一条记录，包含用户ID、文件唯一标识、上传时间戳。
  2. 部署一组监控服务实例，通过Redis消费者组（Consumer Group）分摊Stream中的消息，每个实例处理一部分用户的上传事件，避免重复监控。
  3. 监控服务维护每个用户的最新上传时间戳，若超过设定阈值（比如10秒）无新记录，立即触发邮件通知。
• 客户端交互优化：客户端无需频繁轮询Redis，改为通过WebSocket订阅监控服务的状态推送。监控服务检测到传输中断后，直接推送给用户；若客户端重连，再从Redis拉取历史状态补全。
• 垂直/水平扩缩容支持：
  • 监控服务可通过容器编排工具（如K8s）自动扩缩容，根据Redis Stream的消息堆积量动态调整实例数量。
  • Redis采用集群模式，保证高可用和大吞吐量，避免成为系统瓶颈。
• 备选方案：如果业务规模进一步扩大，可将Redis Stream替换为Kafka，其更高的消息吞吐量和分区能力，能支撑十万级以上用户的并发监控。

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