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

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

需求缘起

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

• 系统发给A的“系统通知”，可能对实时性要求没这么高
• 用户发给A的“聊天消息”，有对实时性要求比较高，越实时越好

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

• 有服务对消息进行逻辑处理
• 有数据库对数据进行落地
• 有缓存对数据进行加速

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

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

方案一、轮询拉取

• 轮询拉取，是最容易想到的实现方式：
• 发送方发送了消息，先入队列
• 网页端起一个timer，每个一段时间（例如10秒）