从 HTTP 轮询到 MQTT：架构演进与实战复盘

在当今这个追求实时交互的时代，用户对消息、通知、数据更新的延迟容忍度越来越低。我们的产品也面临着同样的挑战。早期，我们采用简单直接的 HTTP 轮询 方案来维持客户端与服务器之间的数据同步，但随着用户量增长和业务复杂度的提升，这一方案的弊端日益凸显。最终，我们演进到了基于 MQTT 的实时通信架构。本文将完整复盘这次架构演进的背景、决策过程、实战细节、优化经验与最终收益。

一、旧时代的荣光与阵痛 —— HTTP 轮询

1. 初始方案：HTTP 轮询

• 模式：客户端定时请求服务器，获取是否有新消息。
• 技术栈：Nginx + Spring Boot + Redis + MySQL。
• 优点：实现简单、兼容性强、服务端无状态，能快速上线。

2. 遇到的问题

• 无效请求激增：99% 请求返回“无数据”，浪费数据库和链路资源。
• 延迟难以降低：5 秒间隔 → 平均延迟 2.5 秒；1 秒间隔 → 服务器压力爆炸。
• 带宽与耗电浪费：HTTP 头部开销 + 移动网络不稳定，用户体验差。
• 缺乏主动推送：服务端无法主动通知，很多场景实现别扭。

结论：HTTP 轮询是“伪实时”，规模化后不可持续。

二、寻找解药 —— 为什么是 MQTT？

在考察 WebSocket、SSE、MQTT 后，我们选择了 MQTT。

技术对比