IM 在追求“消息实时性”的架构上,所经历过的几个代表性阶段。
1.短轮询场景
在 PC Web 的早期时代,对于数据的获取,大部分应用采用一问一答的“请求响应”式模式,实际上,像现在我们浏览大部分门户网站的新闻,以及刷微博其实都是采用的“请求响应”模式。但这种依赖“手动”触发的模式,在即时消息系统中当有新消息产生时并不能很好地感知并获取到,所以明显不适用于对实时性要求高的场景。因此,这个时期的 IM 软件很多采用了一种“短轮询”的模式,来定期、高频地轮询服务端的新消息。在短轮询模式中,服务器接到请求后,如果有新消息就会将新消息返回给客户端,如果没有新消息就返回空列表,并关闭连接。
如下图所示:
短轮询缺点:
为了提升实时性,短轮询的频率一般较高,但大部分轮询请求实际上是无用的,客户端既费电也费流量;高频请求对服务端资源的压力也较大,一是大量服务器用于扛高频轮询的 QPS(每秒查询率),二是对后端存储资源也有较大压力。
使用场景:
所以适用于用户规模比较小,且不愿花费太多服务改造成本的小型应用上。
2.长轮询场景
长轮询和短轮询相比,一个最大的改进之处在于:短轮询模式下,服务端不管本轮有没有新消息产生,都会马上响应并返回。而长轮询模式当本次请求没有获取到新消息时,并不会马上结束返回,而是会在服务端“悬挂(hang)”,等待一段时间;如果在等待的这段时间内有新消息产生,就能马上响应返回。
如下图所示:
长轮询缺点:
(1)服务端悬挂(hang)住请求,只是降低了入口请求的 QPS,并没有减少对后端资源轮询的压力。假如有 1000 个请求在等待消息,可能意味着有 1000 个线程在不断轮询消息存储资源。
(2)长轮询在超时时间内没有获取到消息时,会结束返回,因此仍然没有完全解决客户端“无效”请求的问题。
使用场景:
对实时性要求比较高,但是整体用户量不太大。它在不支持 WebSocket 的浏览器端的场景下还是有比较多的使用。
3.WebSocket
随着 HTML5 的出现,全双工的 WebSocket 彻底解决了服务端推送的问题。
和短轮询、长轮询相比,基于 WebSocket 实现的 IM 服务,客户端和服务端只需要完成一次握手,就可以创建持久的长连接,并进行随时的双向数据传输。当服务端接收到新消息时,可以通过建立的 WebSocket 连接,直接进行推送,真正做到“边缘触发”,也保证了消息到达的实时性。
优点:
支持服务端推送的双向通信,大幅降低服务端轮询压力;
数据交互的控制开销低,降低双方通信的网络开销;
Web 原生支持,实现相对简单。
还有其他的基于TCP长连接衍生的通信协议,如 XMPP 协议、MQTT 协议以及各种私有协议。
XMPP :XMPP 协议虽然比较成熟、扩展性也不错,但基于 XML 格式的协议传输上冗余比较多,在流量方面不太友好,而且整体实现上比较复杂,在如今移动网络场景下用的并不多。
MQTT :而轻量级的 MQTT 基于代理的“发布 / 订阅”模式,在省流量和扩展性方面都比较突出,在很多消息推送场景下被广泛使用,但这个协议并不是 IM 领域的专有协议,因此对于很多 IM 下的个性化业务场景仍然需要大量复杂的扩展和开发,比如不支持群组功能、不支持离线消息。
为了更好地解决实时性问题,即时消息领域经历过的几次技术的迭代升级:
1.从简单、低效的短轮询逐步升级到相对效率可控的长轮询;
2.随着 HTML5 的出现,全双工的 WebSocket 彻底解决了服务端推送的问题;
3.同时基于 TCP 长连接衍生的各种有状态的通信协议,也能够实现服务端主动推送,从而更好解决“消息收发实时性”的问题。