我正在开发一个简单的通知服务,用于向浏览网站的用户传递消息.通知不必实时发送,但如果它们的发生频率高于每5分钟发送一次,则可能是更好的用户体验.发送到客户端和从客户端发送的数据不是很大,而且是检索数据的直接数据库查询.
在阅读有关该主题的其他对话时,似乎AJAX推送可能导致更高的服务器负载.由于我可以容忍更长的服务器延迟,因此有必要让服务器推送通知或简单地轮询.
实现推送方案并不困难,所以我想我会看到这里的意见.
谢谢你的帮助.
编辑:我已经研究了一个简单的AJAX推送,并根据Mike Purvis的这篇文章实现了一个简单的演示.对于初始版本,客户端负载相当低,大约为5k,并且预计会在相当长的一段时间内保持这种状态.
谢谢大家的回复.我已决定使用轮询解决方案,但将其全部包装在实用程序库中,这样如果他们想稍后更改它就会更容易.
我很惊讶这里没有提到长轮询.长轮询意味着保持打开连接更长时间(比如说30-60秒),一旦关闭,再次重新打开它,只需让插座/连接听取响应.这导致更少的连接(但更长的连接),并且意味着响应几乎是立即的(一些可能必须等待新的轮询连接).我想补充一点,结合NodeJS等技术,这将产生一个非常有效且资源轻的解决方案,在所有主流浏览器和版本中100%浏览器兼容,并且不需要任何其他技术,如Comet或闪.
我意识到这是一个老问题,但认为提供这些信息可能仍然有用:)
绝对使用推动它更酷.如果您只是想要简单的通知,我会使用像StreamHub Push Server这样的东西为您做繁重的工作.开发自己的Ajax Push功能是一个非常棘手和艰难的道路 - 你必须让它在所有浏览器中工作,然后处理防火墙和代理,杀死保持连接等...为什么重新发明轮子.此外,它具有同样低于10K的足迹,因此如果这是您的优先考虑,它应该适合.
两者都有不同的要求,并解决不同的情况.
如果您需要实时更新,例如在线聊天,那么推送是必须的.
但是,如果刷新周期很大,就像你的情况一样(5分钟),那么pool就是合适的解决方案.在这种情况下,推送将需要来自客户端和服务器的大量资源.
小费!尝试使检查池的页面快速清理,因此在每个请求中它不会消耗服务器中的大量资源.我通常做的是在内存中保留一个标志(比如在一个会话变量中),该标志表示池是否为空......所以,我只在不是空的情况下才在池中查看havy.当池为空时(大多数情况下),页面请求运行得非常快.
因为使用推送需要在服务器和每个客户端之间维护一个开放的HTTP连接,所以我也会进行轮询 - 这不仅会消耗大量的服务器资源,而且对于它来说也会变得非常棘手.实现为亚光b提到.
我在轮询方面的经验是,如果您在足够忙碌的站点上有足够频繁的轮询间隔,那么您的Web服务器日志可能很快就会被轮询请求充斥.
编辑(2017):我说你的选择现在是在websockets和长轮询之间(在另一个答案中提到).听起来像长轮询可能是正确的选择,基于问题提到不需要实时接收通知的方式,不频繁的轮询期很容易实现,不应该对你的服务器非常负担. .如今,Websockets很酷,是许多应用程序的绝佳选择,但在这种情况下听起来可能有点过头了.