轮询RSS源的策略是什么？

Question

我有一个应用程序，它轮询网络上的多个RSS源。

当轮询其他人的Web服务器时，有什么礼仪？轮询频率应该是多少等等？

有哪些最佳实践？

- flybywire

Answer 1

1. 利用HTTP缓存。发送Etag和LastModified头部。识别304 Not Modified响应。这样可以节省大量带宽。此外，一些脚本可以识别LastModified头部并仅返回部分内容（例如，仅返回最新的两三个项目而不是所有30个左右的项目）。

2. 不要从支持RPC Ping（或其他PUSH服务，如PubSubHubbub）的服务中轮询RSS。也就是说，如果您从服务中接收到推送通知，您不必在标准间隔内轮询数据 - 只需每天检查一次机制是否仍然有效即可（ping可能被禁用、重新配置、损坏等）。这样，只有在收到通知时才能获取RSS，而不是每小时获取一次。

3. 检查TTL（在RSS中）或缓存控制头部（ATOM中的Expires），并在资源过期之前不要获取。

4. 尝试适应每个单独的RSS源中新项目的频率。如果在特定源中过去一周只有两个更新，请不要超过一天获取一次。AFAIR Google Reader就是这样做的。

5. 在夜间或其他网站流量较低的时间降低频率。

6. 最后，每小时执行一次。 ;)

- Maciej Łebkowski

---

我应该把#6理解为“每小时不要重复执行超过一次”还是“每小时至少执行一次”？ - PypeBros

如果没有其他规则适用，每小时只执行一次。 - Maciej Łebkowski

Answer 2

谷歌的FeedFetcher声称它每小时轮询一次rss feed。

来源：http://code.google.com/apis/ajaxfeeds/documentation/ 引用：

订阅源爬取频率

由于谷歌AJAX Feed API使用Feedfetcher，因此来自AJAX Feed API的订阅源数据可能不总是最新的。谷歌订阅源爬虫（“Feedfetcher”）检索大多数站点的订阅源时间少于每小时一次。一些更新频繁的站点可能会更频繁地刷新。

- Jonathan Fingland

---

自从code.google.com不存在后，该链接已失效。截至2016年10月19日，文档仍得到支持，请前往https://support.google.com/webmasters/answer/178852?hl=en查看。 - lordoku

Answer 3

我会忽略那些说“Google说了，我们就这样做”的帖子，我要说的是：你需要根据实际情况尽可能频繁地更新。

RSS可以让你及时了解最新信息。如果一个RSS源每小时发布10个项目，但只显示5个，那么你将错过5个项目，这个RSS源就没有达到其目的。你还不如不去请求它。

当然，你不能用大量请求来占用服务器资源，但如果他们发布的内容足够让你每分钟请求一次，我认为以同样的速度请求是合理的。

- Oli

---

你会注意到谷歌参考还指出，他们对于频繁更新的订阅源使用更高的速率。 - Jonathan Fingland

我的观点是（我同意这并不是最好的表达方式，因为我没有完全阅读引用），即谷歌并不一定是最佳实践或道德的全部和终极标准。 - Oli

Answer 4

每小时一次，如果你只是想按经验法则走（但链接解释了一些更好的选择）。

- Bill the Lizard

Answer 5

每小时一次是我听过的频率。

- cgp

Answer 6

这不是一个完整的答案，但可以寻找推送警报。

RSS博客指出，最佳实践是询问weblogs.com有关更改的博客。

还有一些关于pubsub的喧闹，这是一种订阅推送警报的方式，具有一定的动力。

- dfrankow

Answer 7

我注意到 Twitter 使用（自定义）X-RateLimit-Remaining 和 X-RateLimit-Limit 头部（在 HTTP 响应中）来指示 Atom feeds 的最大授权投票数。有点遗憾的是，他们没有使用标准的 Expires 字段（它被设置为 30 年前 :P），我猜想他们广告中的 Cache-Control: no-cache 也排除了 RFC 2616（第 13.2.* 节）中定义的通用启发式过期时间。更遗憾的是，Atom 似乎没有提供任何标准化的方法来告诉用户建议多久轮询一次 feed。

- PypeBros

Answer 8

RSS中有一个TTL设置，因此当TTL过期时，您应该只进行轮询。

但是，我猜如果他们没有设置TTL，那就是他们的问题了，您应该每小时轮询一次之类的。

- Sruly