8

我一直在为 Stack Exchange 编写 Google Chrome 扩展程序。这是一个简单的扩展，可让您跟踪您的声誉并在 Stack Exchange 网站上收到评论通知。

目前我遇到了一些我自己无法处理的问题。我的扩展使用 Google App Engine 作为后端向 Stack Exchange API 发出外部请求。扩展程序对单个站点上的新评论的每个单个客户端请求都可能导致对 api 端点的大量请求以准备响应，即使对于非 skeetish 用户也是如此。普通用户至少在 Stack Exchange 网络的 3 个站点上拥有帐户，有些拥有 > 10 个！

Stack Exchange API 有请求限制：
单个 IP 地址每天只能发出一定数量的 API 请求（10,000）。
如果我在 5 秒内从单个 IP 地址发出超过 30 个请求，API 将切断我的请求。

很明显，所有请求都应限制为每 5 秒 30 次，目前我已经基于带有 memcached 的分布式锁实现了请求限制逻辑。我使用 memcached 作为一个简单的锁管理器来协调 GAE 实例的活动并限制 UrlFetch 请求。
但我认为将如此强大的基础设施限制为每 5 秒发出不超过 30 个请求是一个很大的失败。这样的 api 请求率不允许我继续开发新的有趣和有用的功能，并且有一天它会完全停止正常工作。
现在我的应用程序有 90 个用户并且还在增长，我需要提出如何最大化请求率的解决方案。

众所周知，App Engine 通过相同的不同 IP 池发出外部 UrlFetch 请求。我的目标是编写请求限制功能，以确保符合 api 使用条款并利用 GAE 分布式功能。

所以我的问题是如何在遵守 api 使用条款和利用 GAE 分布式功能的同时提供最大的实际 API 吞吐量。

建议使用另一个平台/主机/代理在我看来是没用的。

4

2 回答 2

4

如果您正在寻找一种以编程方式管理 Google App Engine 共享 IP 池的方法，我坚信您不走运。

无论如何，引用这个作为常见问题解答一部分的建议，我认为你有更多的机会继续运行你的真棒应用程序：

如果我每天需要更多请求，我该怎么办？

某些类型的应用程序 - 仅举两个例子的服务和网站 - 可以合法地比典型应用程序具有更高的每日请求要求。如果您可以证明需要更高的请求配额，请联系我们。

编辑：
我错了，实际上你没有任何机会。
Google App Engine [app]注定要失败。

于 2010-10-16T20:45:51.903 回答
2

首先：我正在使用您的扩展程序，它很震撼！

您是否考虑过使用memcached并缓存结果？
与其直接从 API 获取结果，不如先尝试在缓存中找到它们，如果它们正在使用，如果没有：检索它们并缓存它们，让它们在 X 分钟后过期。

其次，尝试批量处理用户请求，而不是询问单个用户的信誉，而不是一起询问多个用户的信誉。

于 2010-10-16T18:03:57.673 回答