我不知道像Google Reader，Blogline，techronati这样的网络应用程序，以及他们采用什么技术来一次分析使用cron工作的数百万RSS源？
有很多不同的技术，“最糟糕的”一个是你描述的。 (基于时间的投票)。
您需要考虑的第一件事是它们可能并不都在服务器端进行解析。例如，我知道Netvibes正在客户端进行解析(但是缓存了服务器上的内容)，所以它节省了大量的资源。这样他们只会在用户询问他们时轮询Feed，所以不需要他们运行某种时间循环。
基于时间的轮询仍然是不寻常的解决方案。有很多技巧可以确定什么时候进行投票的最佳时机。基于过去更新的频率，基于susbc …等的用户数量。旧的XML-RPC ping服务器也可以由这些人使用。
最有效的技术是使用PubSubHubbub，这是Google Reader，Netvibes和其他几千个应用(如Digg.com，TwitterFeed，FriendFeed …)使用的开放协议。这是一个开放协议，允许Feed发布者直接将Feed的内容推送到订阅应用程序。这是非常有效的，但要求发布商实现它。偶然的是，所有的大型博客平台(Tumblr，Posterous，wordpress，Blogger，SixApart …等)都实现了这一点。其他Feed发布应用(如Feedburner，Gowalla，…)也实现了它。如果您发布Feed，我会鼓励加入这个人群，如果你打算消费一些，请执行susbcriber方面。
最后一个解决方案是使用第三方应用程序进行此数据收集(使用上述所有技术)，并在这些Feed实际上具有新内容时对其进行ping。我创建了一个：Superfeedr，我相信我们做得很好。我们也规范了内容，并做了一些其他的事情，以帮助您以最简单和最便宜的方式消费饲料数据(投票可能是疯狂的昂贵)。此外，我们使用完全相同的PubSubHubbub协议从任何Feed推送内容，这使得我们的用户除了订阅可用的集线器之外，还使用我们的服务非常简单。
