远程服务缓存策略；我应该考虑什么？

Question

我的网络应用包含从我无法控制的外部 API 收集的数据。我限制在每小时大约 20,000 个 API 请求。我的数据库中有大约 250,000 个项目。这些项目中的每一个本质上都是一个缓存版本。考虑更新 1 个项目的缓存需要 1 个请求。显然，在这些情况下不可能有一个完全最新的缓存。那么，在制定缓存数据的策略时，我应该考虑哪些事情。这些是我想到的事情，但我希望有人有一些我没有想到的好主意。

• 自项目创建以来的时间（时间越短越重要）
• 特定项目的“赞”数（可能意味着被查看的概率更高）
• 自上次更新以来的时间

更多细节：这些项目是照片。每张照片都属于一个事件。当前发生的事件更喜欢被客户查看（因此它们应该优先）。虽然我现在数据库中只有 25 万个项目，但这个数字增长得相当快（很快就会达到 100 万个大关，可能需要 5 个月）。

Answer 1

http://instagram.com/developer/realtime/ 有用吗？当有新的（可能是更新的？）图像供您查看时，Instagram 似乎愿意发布到您的服务器。这样能行吗？

否则，我认为您的问题听起来很像任何搜索引擎的问题——您见过Wikipedia on crawler selection criteria 吗？您正在处理网络爬虫所面临的许多问题：要爬取什么、多久爬一次，以及如何避免对单个站点发出过多请求。您还可以查看open-source crawlers（在同一页面上），了解您可能能够学习的代码和算法。

不管怎样，抛出一些关于爬行标准的想法：

• 更新更新时经常更改的内容。因此，如果某个项目在最近五次更新中没有发生变化，那么也许您可以假设它不会经常更改并减少更新。
• 为每个图像创建一个分数，并更新分数最高的那些。或最低分数（取决于您使用的分数类型）。这与 LilyPond 对typeset music 使用的想法类似。为此类分数创建输入的一些方法：
  • 图像被更新并需要重新缓存的可能性的统计模型。
  • 每张图片的重要性分数，使用图片的新近度或事件的流行度等。
• 更新经常查看的内容。
• 更新有很多视图的东西。
• 时间会影响图像更新的概率吗？您提到新图像更重要，但是旧图像发生变化的概率呢？减慢检查旧图像的频率。
• 将请求的一部分分配给缓慢更新所有内容，并将其他部分分开以同时处理来自几种不同算法的结果。因此，例如，具有以下内容（数字仅用于展示/示例-我只是将它们从帽子中拉出来）：
  • 每小时 5,000 个请求在数据库的完整内容中翻腾（前提是自上次抓取工具通过以来未更新）
  • 2,500 个请求处理新图像（您提到的更重要）
  • 2,500 个请求处理当前事件的图像
  • 2,500 个请求处理查看次数最多的前 15,000 个图像（只要该图像的最后 5 次检查有变化，否则，按递减的时间表检查）
  • 2,500 个请求处理至少已查看的图像
  • 总计：每小时 15,000 个请求。

Answer 2

每小时在您的网站上查看多少（独特的）照片/活动？那些未查看的照片可能不需要经常更新。您在旧事件/电话的视图中看到任何模式吗？旧事件可能不那么受欢迎，因此也许不必经常检查它们。

andyg0808 有很好的详细信息，但在实际应用之前了解您的数据使用模式很重要。

有时您会发现每小时 20,000 个 API 请求不足以更新经常查看的照片，这也可能导致您遇到不同的问题。