我正在开发一个简单的通知服务，该服务将用于向浏览网站的用户传递消息。通知不必实时发送，但如果它们发生的频率高于每 5 分钟一次，则可能会带来更好的用户体验。发送到客户端和从客户端发送的数据不是很大，它是一个直接的数据库查询来检索数据。
在阅读有关该主题的其他对话时，似乎 AJAX 推送会导致更高的服务器负载。由于我可以容忍更长的服务器延迟，因此值得让服务器推送通知或简单地轮询。
实现推送场景并不难，所以我想我会在这里看到意见。
谢谢你的帮助。
编辑：我研究了一个简单的 AJAX 推送，并根据Mike Purvis的这篇文章实现了一个简单的演示。初始版本的客户端负载相当低，约为 5k，预计会在相当长的一段时间内保持这种状态。
谢谢大家的回复。我决定使用轮询解决方案，但将其全部包装在一个实用程序库中，这样如果他们以后想更改它就更容易了。
我很惊讶这里没有人提到长轮询。长轮询意味着保持打开的连接更长的时间（比如 30-60 秒），一旦它关闭，再次重新打开它，并简单地让套接字/连接监听响应。这导致更少的连接（但更长的连接），并且意味着响应几乎是即时的（有些可能必须等待新的轮询连接）。我想补充一点，结合 NodeJS 之类的技术，这会产生一个非常高效且资源轻的解决方案，即 100% 兼容所有主要浏览器和版本的浏览器，并且不需要任何额外的技术，如 Comet 或闪光。
我意识到这是一个老问题，但认为提供这些信息可能仍然有用:)
绝对使用推它更酷。如果您只想要简单的通知，我会使用StreamHub Push Server之类的东西来为您完成繁重的工作。开发您自己的 Ajax Push 功能是一条非常棘手和崎岖的道路——您必须让它在所有浏览器中工作，然后处理防火墙和代理，杀死保持连接等......为什么要重新发明轮子。此外，它的占用空间也非常低，不到 10K，因此如果这是您的优先事项，它应该适合您。
两者都有不同的要求并针对不同的场景。
如果您需要实时更新，例如在线聊天，推送是必须的。
但是，如果刷新周期很大，就像您的情况（5 分钟）一样，那么 pool 是合适的解决方案。在这种情况下，推送将需要来自客户端和服务器的大量资源。
提示！尽量使检查池的页面快速而干净，这样它就不会在每个请求中消耗服务器中的大量资源。我通常做的是在内存中保留一个标志（如在会话变量中），说明池是否为空......所以，只有当池不为空时，我才会在池中查看。当池为空时（大多数情况下），页面请求运行得非常快。
因为使用推送需要在您的服务器和每个客户端之间维护一个开放的 HTTP 连接，所以我也会选择 poll ——这不仅会消耗大量服务器资源，而且要更加棘手按照提到的matt b实施。
我的轮询经验是，如果您在一个足够繁忙的站点上有足够频繁的轮询间隔，您的 Web 服务器日志可能很快就会被轮询请求淹没。
编辑（2017）：我想说你现在的选择是在 websockets 和长轮询之间（在另一个答案中提到）。听起来长轮询可能是正确的选择，具体取决于问题提到不需要实时接收通知的方式，不频繁的轮询周期很容易实现，并且不应该对您的服务器造成很大负担. Websockets 很酷，并且是当今许多应用程序的绝佳选择，但在这种情况下听起来可能有点矫枉过正。
我会实施民意调查只是因为它听起来更容易编写，并且保持简单非常有价值。
不确定您是否看过一些 COMET 实现（这就是您所说的 AJAX 推送）。
如果用户正在浏览该站点，那实际上是不是从服务器请求信息，该通知可以搭载该通知？
我自己没有尝试过，但有人说COMET 有效，而且比你想象的要容易。还有一个名为Juggernaut的 Ruby on Rails 插件，我听说它得到了高度评价。同样，我没有使用它，所以 YMMV，但我的理解是，与轮询相比，它需要的资源要少得多。我相信（有人可以证实吗？）COMET 是MacRumorsLive.com提供 WWDC Stevenotes 实时博客的方式。
在不知道您将拥有多少客户的情况下，不可能说轮询是否会比推送更昂贵。我建议投票，因为：
cometd在服务器端和客户端库之类的东西来处理服务器端推送。因此，如果您需要一些繁重的任务来管理大量数据和大量客户端，我建议您使用 Comet。但情况似乎并非如此。
现在有一个服务http://pusherapp.com试图一劳永逸地解决这个问题。可能值得一试。（免责声明：我与他们没有任何关系）。