在 Google App Engine Cloud 基础架构上实现 Stack Exchange API 兼容请求限制

Posted 2023-04-14

【中文标题】在 Google App Engine Cloud 基础架构上实现 Stack Exchange API 兼容请求限制

【英文标题】：Stack Exchange API compliant request throttle implementation on Google App Engine Cloud infrastructure

【发布时间】：2011-04-26 09:01:04

【问题描述】：

我一直在写a Google Chrome extension for Stack Exchange。这是一个简单的扩展程序，可让您跟踪您的声誉并在 Stack Exchange 站点上收到有关 cmets 的通知。

目前我遇到了一些我自己无法处理的问题。 我的扩展使用 Google App Engine 作为后端向 Stack Exchange API 发出外部请求。来自单个站点上新 cmets 扩展的每个单个客户端请求都可能导致对 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 吞吐量。

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

【问题讨论】：

所以你的 chrome 扩展正在向你的服务器发送请求，然后你的服务器正在向堆栈 API 发送请求？是否可以直接从chrome调用stack api？

@serg，是的，这是可能的，但这意味着扩展程序将不断地为每个用户的帐户向 api 端点发出大量请求。将此乘以用户帐户的数量。此外，它还需要额外的权限才能从扩展访问 api 端点。但是，是的，现在我正在考虑这个解决方案

如果他们允许来自单个 api 的 10k 个请求，那么我认为他们可以处理它。

@Vladislav App Engine 应用程序不是必须代表用户发出与用户直接发出的请求一样多的请求吗？

【参考方案1】：

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

无论如何，引用 faq 中的这条建议，我认为您有更多机会继续运行您的出色应用：

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

某些类型的应用程序 - 服务和网站仅举两个 - 可以合法地拥有更高的 每天的请求要求比 典型应用。如果你可以的话 表明需要更高的 申请配额，联系我们。

编辑： 我错了，其实你没有任何机会。 Google App Engine [app] 是 doomed。

【讨论】：

谢谢@systempuntoout，我知道这种可能性。我可以以某种方式解决每个 IP 请求限制 10,000 个问题，但实际上，我主要需要扩展请求“速度”，比如每秒 30 个或更多，但无论如何，他们说“请仅在您的应用程序处于活动状态并且没有- 微不足道的用户数量”。我不确定 100 甚至 1000 是不是微不足道的用户数。

考虑到以编程方式管理 App Engine 的 IP 池，我当时也开始认为这是不可能的。可能我会在 GAE 问题跟踪器中填写一个问题。

@Vladislav 正如您所说，您应该将业务逻辑移至浏览器（IP 不是问题），例如采用 SOAPI.js 等成熟的 js 库。

是的，所有外观，目前它是唯一的解决方案:(

【参考方案2】：

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

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

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

【讨论】：

感谢您使用它。是的，我大量使用 memcached 来缓存 API 响应，但即使这样也不能帮助我大大减少 api 请求的数量。批量请求的想法对我很有帮助，谢谢。

@Vlasislav 这有点好笑，我、shay 和你正在争夺相同的配额，因为我们所有人都有一个在 GAE 上运行的 Web 应用程序。马上发现！ stackapps.com/questions/1708/…

@Vlasislav stackapps.com/questions/1713/…