我们在设计网站的时候，总会遇到一些消息的接收业务。
例如：做个电商网站，买卖双方需要能够实时的沟通。
例如：业务系统需要实时的反馈一些员工活动的情况。
那么这个时候，网页端怎么高效的收到这些消息，就是我们在系统设计时需要考虑的了。当然，任何的方法，都是以业务为前提的，我们选择的并不是最完美的解决方案，我们只需要选择最合适的方式。
一般来说，对于网页端的用户，对于消息的要求就那么2种。
- 系统的通知类的消息，消息的频率不高，实时性要求也不高。
- 聊天类的消息，消息评率高，实时性要求也高。
那么，针对这些场景，我们无论是将消息放到数据库里，还是缓存里，还是队列里处理，这个就根据我们的请求体量了。
我们假设，消息都是通过队列来处理的。
那么，常用的处理的方式有3种：短轮询、长连接、长轮询。
短轮询
短（传统）轮询很好理解，就是我在网页端做了一个计时器，每隔一段时间，我就想服务器发起一次请求，如果有新消息，就返回消息，如果没有新消息，就返回null，然后如此循环。
这种方式的优势非常也明显：
- 实现简单，一个js就搞定了。
- 理解容易，没有什么高深的技术，一说就明白。
在互联网兴起的初期，很多聊天室就是这么实现的，当然，基本都是一些小聊天室。
当然，明显的优势带来的也是明显的缺点：
- 实时性差，轮询间隔不能太小，不然就对服务器造成了不小的压力，这样就导致了消息的实时性差。
- 效率低，如果请求没有返回消息，那么这个请求相当于就是无效的，无效的请求一旦多了，就造成了大量的资源浪费。
所以，使用此方式，效率和时效是相悖的，因此，这种方式只能用在访问量少，不考虑效率的场景中。
长连接
长连接是解决时效性和效率的有效方式，而且不管在效率还是时效性方面都非常的优秀。具有代表性的技术就是websocket。
那么，长连接既然这么优秀，是不是就没有什么缺点了呢？
其实并不是的，websocket的缺点也是比较明显的。
- 浏览器的兼容性差，对于很多还在使用IE 8的用户来说，这个技术还在未来。
- 对程序员开发要求稍高，我们需要对接口进行一些处理，用户维持WebSocket的连接。
长轮询
长轮询的核心点在于，浏览器和服务器之间建立了一条通知连接。这条连接只会处理消息通知的推送。
这个HTTP的连接和普通的HTTP连接不同，这个HTTP连接会被服务器Hold住，直到有消息需要返回或者到达约定的时间。
对于HTTP的请求来说，当浏览器请求服务器时，如果长时间没有数据返回，这个请求会因为超时被断开。而长轮询的请求会设置一个时间阈值，当快要到达超时的时间点前，服务端返回一个空消息，避免连接被强行断开。
我们通过一个简单的流程图来看一看吧。
这样，我们就及解决了短轮询中的效率和实效的问题，有解决了长连接中的兼容性问题。
当然，最终我们使用哪种方式，还是根据实际的业务场景。
閱讀更多 會技術的葛大爺 的文章
