网页端收消息，究竟是推还是拉？

任何脱离业务的架构设计都是耍流氓。网页端收消息，究竟是推还是拉？

 

需求缘起

对于在网页端登录的用户A，发送方，也就是消息的来源有几方面：

• 系统发给A的“系统通知”，可能对实时性要求没这么高

• 用户发给A的“聊天消息”，有对实时性要求比较高，越实时越好

 

消息的处理方，也就是系统侧，一般来说：

• 有服务对消息进行逻辑处理

• 有数据库对数据进行落地

• 有缓存对数据进行加速

抛开这些技术细节不谈，暂且认为服务端对每一个用户都有一个“待收消息”的队列，里面存放了需要给这个用户的一切消息。

 

消息的接收方，也就是用户A，如果是在网页端登录，因为HTTP协议是“请求-响应”式的，服务端与网页之间没有消息通道，对于这类“收消息”的需求，是如何处理的呢？

 

方案一、轮询拉取

轮询拉取，是最容易想到的实现方式：

• 发送方发送了消息，先入队列

• 网页端起一个timer，每个一段时间（例如10秒&#x