前端接收消息的推和拉

        我们在设计网站的时候，总会遇到一些消息的接收业务。

        例如：做个电商网站，买卖双方需要能够实时的沟通。

        例如：业务系统需要实时的反馈一些员工活动的情况。

        那么这个时候，网页端怎么高效的收到这些消息，就是我们在系统设计时需要考虑的了。当然，任何的方法，都是以业务为前提的，我们选择的并不是最完美的解决方案，我们只需要选择最合适的方式。

        一般来说，对于网页端的用户，对于消息的要求就那么2种。

        1.系统的通知类的消息，消息的频率不高，实时性要求也不高。

        2.聊天类的消息，消息评率高，实时性要求也高。

        那么，针对这些场景，我们无论是将消息放到数据库里，还是缓存里，还是队列里处理，这个就根据我们的请求体量了。

        那么，常用的处理的方式有3种：短轮询、长连接、长轮询。

        1、短轮询

        短（传统）轮询很好理解，就是我在网页端做了一个计时器，每隔一段时间，我就想服务器发起一次请求，如果有新消息，就返回消息，如果没有新消息，就返回null，然后如此循环。

        这种方式的优势非常也明显：

                1)、实现简单，一个js就搞定了。

                2)、理解容易，没有什么高深的技术，一说就明白。

        在互联网兴起的初期，很多聊天室就是这么实现的，当然，基本都是一些小聊天室。

        当然，明显的优势带来的也是明显的缺点：

                1)、实时性差，轮询间隔不能太小，不然就对服务器造成了不小的压力，这样就导致了消息的实时性差。

                2)、效率低，如果请求没有返回消息，那么这个请求相当于就是无效的，无效的请求一旦多了，就造成了大量的资源浪费。

        所以，使用此方式，效率和时效是相悖的，因此，这种方式只能用在访问量少，不考虑效率的场景中。

        2、长连接

        长连接是解决时效性和效率的有效方式，而且不管在效率还是时效性方面都非常的优秀。具有代表性的技术就是websocket。

        那么，长连接既然这么优秀，是不是就没有什么缺点了呢？

        其实并不是的，websocket的缺点也是比较明显的。

                1)、浏览器的兼容性差，对于很多还在使用IE 8的用户来说，这个技术还在未来。

                2)、对程序员开发要求稍高，我们需要对接口进行一些处理，用户维持WebSocket的连接。

        3、长轮询

        长轮询的核心点在于，浏览器和服务器之间建立了一条通知连接。这条连接只会处理消息通知的推送。

        这个HTTP的连接和普通的HTTP连接不同，这个HTTP连接会被服务器Hold住，直到有消息需要返回或者到达约定的时间。

        对于HTTP的请求来说，当浏览器请求服务器时，如果长时间没有数据返回，这个请求会因为超时被断开。而长轮询的请求会设置一个时间阈值，当快要到达超时的时间点前，服务端返回一个空消息，避免连接被强行断开。

            我们通过一个简单的流程图来看一看吧。

            这样，我们就及解决了短轮询中的效率和实效的问题，有解决了长连接中的兼容性问题。

            当然，最终我们使用哪种方式，还是根据实际的业务场景。

• 上一篇： 服务器推送---html5 websocket的使用
• 下一篇： MySQL必备命令速查手册