客户端通知,我应该使用AJAX推送还是轮询?

我很惊讶这里没有人提到长期民意调查。长轮询意味着将打开的连接保持更长的时间(比如30-60秒),一旦关闭,再次打开,让套接字/连接监听响应。这会导致更少的连接(但更长的连接),并意味着响应几乎是即时的(有些可能必须等待新的轮询连接)。我想补充一点,结合NodeJS等技术,这将产生一个非常高效、资源量小的解决方案,在所有主要浏览器和版本上都是100%兼容的,不需要任何额外的技术,如Comet或Flash。

我意识到这是一个老问题,但我认为提供这些信息可能仍然有用:)

一定要用推它更凉。如果你只想要简单的通知,我会使用类似的东西 StreamHub Push Server 为你完成这项繁重的任务。开发自己的Ajax Push功能是一条极其棘手和崎岖的道路——你必须让它在所有浏览器中都能工作,然后处理防火墙和代理,杀死存活连接等。为什么要重新发明轮子。此外,它的占地面积同样很小,不到10K,所以如果这是你的优先事项,它应该很适合。

两者都有不同的要求,并针对不同的场景。

如果你需要 实时更新 就像在线聊天一样,推送是必须的。

但是,如果 刷新周期大 ,就像你的情况一样(5分钟),那么池是合适的解决方案。在这种情况下,推送将需要来自客户端和服务器的大量资源。

小费! 尝试使检查池的页面快速干净,这样它就不会在每次请求中消耗服务器中的大量资源。我通常会在内存中保留一个标记(如会话变量中),表示池是否为空。..所以,只有当游泳池不是空的时候,我才会去看看。当池为空时,这是大多数时候,页面请求运行得非常快。

因为使用推送需要在服务器和每个客户端之间保持开放的HTTP连接,所以我也会选择轮询——这不仅会消耗大量的服务器资源,而且正如matt b提到的那样,实现起来也会更加棘手。

我对轮询的经验是,如果你在一个足够繁忙的网站上有足够频繁的轮询间隔,你的网络服务器日志可能会很快被轮询请求淹没。

编辑(2017) :我想说你现在的选择是在websockets和长轮询之间(在另一个答案中提到)。听起来长轮询可能是正确的选择,因为问题提到通知不需要实时接收,不频繁的轮询期很容易实现,而且不会对服务器造成太大负担。如今,Websockets很酷,是许多应用程序的绝佳选择,但在这种情况下,这听起来可能有些过头了。

我会实施一个民意调查,只是因为它听起来更容易编写,保持简单是非常有价值的。

不确定您是否看过一些COMET实现(这就是您所说的AJAX推送)。

如果用户正在浏览网站,这难道不是在向服务器请求信息,而这个通知可以利用这些信息吗?

在不知道你会有多少客户的情况下,不可能说民意调查是否会比推送更昂贵。我建议投票,因为:

• 听起来你想每分钟更新一次数据。除非通知能够以比这快得多的速度到达,否则推送意味着你保持HTTP连接打开,但看到的活动很少。
• 轮询是建立在现有HTTP约定之上的,因此任何与web浏览器通信的服务器都已经准备好响应普通的Ajax请求。基于Comet或Flash套接字的解决方案有不同的要求;你需要这样的东西 cometd 在服务器端,以及一个探索服务器端推送的客户端库。

因此,如果你需要一些繁重的任务来管理大量数据和大量客户端,我建议你使用Comet。但事实似乎并非如此。

现在有一项服务 http://pusherapp.com 它试图在一眨眼之间一劳永逸地解决这个问题。可能值得一看。(免责声明:我与他们没有任何关系)。

我自己还没试过,但有人说 COMET works and is easier than you think 。还有一个名为Ruby on Rails的插件 Juggernaut 这是我听人高度评价的。同样,我没有使用它,所以YMMV,但我的理解是,与轮询相比,它需要的资源要少得多。我相信(有人能证实吗?)COMET是怎么回事 MacRumorsLive.com 提供WWDC Stevenotes的实时博客。