我想知道像 Google Reader、Logline、technorati 这样的 Web 应用程序是如何工作的，以及它们遵循哪些技术使用 cron 作业一次性解析数百万个 RSS 提要？
有一个lot不同的技术......“最糟糕”的技术就是您所描述的技术。 （基于时间的轮询）。
您需要考虑的第一件事是它们可能并不都在服务器端进行解析。例如，我知道Netvibes在客户端进行解析（但将内容缓存在服务器上），因此它节省了他们很多资源。这样他们就会仅当用户向他们询问，所以他们不需要运行某种时间循环。
不幸的是，基于时间的轮询仍然是最常见的解决方案。有很多技术可以确定何时是进行民意调查的最佳时间。基于过去更新的频率、基于订阅的用户数量……等等。这些人也可以使用旧的 XML-RPC ping 服务器。
最有效的技术是使用PubSubHubbub https://github.com/pubsubhubbub，这是 Google Reader、Netvibes 和数千个其他应用程序（如 Digg.com、Twitterfeed、Friendfeed...）使用的开放协议。它是开放协议允许 feed 发布者直接将 feed 内容推送到订阅应用程序。它非常有效，但需要发布者来实施。偶然地，所有大型博客平台（Tumblr、Posterous、Wordpress、Blogger、SixApart...等）已经实现了它。其他提要发布应用程序（如 feedburner、Gowalla 等）也实现了它。如果您确实发布了提要，我会鼓励您加入这个人群，如果您打算消费一些提要，请也实现订阅者方面。
最后一个解决方案是使用第三方应用程序进行数据收集（使用上述所有技术），并在这些源实际上有新内容时向您发出通知。我创建了一个：超级喂食器 http://superfeedr.com我相信我们在这方面做得很好。我们还规范化内容并执行其他一些操作来帮助您以最简单且廉价的方式使用提要数据（轮询可能非常昂贵）。还，我们使用完全相同的 PubSubHubbub 协议从任何源推送内容，这使得我们的用户除了订阅可用的中心之外还可以非常简单地使用我们的服务。
另外，我应该补充一点，我能够快速回复您的问题，因为我使用的应用程序可以推送标记为 RSS 的问题提要的内容:)
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
