multithreading - 当客户端是多线程时，客户端对 HTTP 429 的正确 react 是什么？

Question

HTTP 状态代码 429 告诉发出请求的客户端在响应的 Retry-After header 中指定的时间段后退出并重试请求。

在单线程客户端中，很明显得到 429 的线程应该按照指示等待，然后重试。但是 RFC明确指出

this specification does not define how the origin server identifies the user, nor how it counts requests.

因此，在多线程客户端中，保守的方法会阻止所有线程发送请求，直到 Retry-After 时间点。但是:

• 许多线程可能已经过了可以记录来自一个被拒绝线程的信息的程度，并将至少再发送一个请求。
• 线程之间的全局同步可能很难实现和正确执行
• 如果设置不仅运行多个线程而且运行多个客户端(可能在不同的机器上)，那么在一个 429 上将所有线程都关闭就变得非常重要。

是否有人从现场获得了云提供商的服务器实际如何处理此问题的具体数据？如果我不全局阻止所有线程，它们会立即恶化吗？ Microsoft's advice是

1. Wait the number of seconds specified in the Retry-After field.
2. Retry the request.
3. If the request fails again with a 429 error code, you are still being throttled. Continue to use the recommended Retry-After delay and retry the request until it succeeds.

它两次说“请求”而不是“任何请求”或“所有请求”，但这是我不确定的法律类型解释。

为确保这不是一个意见问题，让我尽可能以事实为基础来表述它:

是否有比上面示例更详细的云 API(Microsoft、Google、Facebook、Twitter)规范，使我能够做出明智的决定，是否需要全局回退，或者是否足以通过特定的回退请求得到了 429？

Answer 1

服务器知道同步或期望程序员执行此操作很重要。所以怀疑是否会有惩罚，除非他们收到大量在 429 之后根本不退缩的请求。

每个线程都应该等待，但在被单独告知后，每个线程都会等待。

一个好的系统会知道它的速率是多少并在其中。实现这一点的一种方法是在请求之间设置一个 sleepFor 变量。确切的产品值可以通过反复试验得出，它是 sleep 时间减去之前的请求时间。

因此，如果一个请求结束，并说它花费了 x 毫秒。现在如果 sleep 时间是 0 或更少，立即移动到下一个请求 如果 1 或大于 sleepTime - x，如果小于 1，则立即转到下一个，否则休眠这么多毫秒，然后转到下一个请求。

另一种方法是在请求 1 处设置一个 timeCountStrarted；每5分钟左右计数一次。每次请求后，检查当前线程的实际请求数是否大于该数。如果是，当前线程会休眠 5 分钟，然后再转到下一个。这里5可以配置为timePeriod。如果请求后计数不超过设定值，但自 timeCountStrarted 以来耗时超过 5 分钟；然后将 timeCountStrarted 设置为当前时间，并将请求计数设置为 0。

我们所做的是将这些配置值保存在数据库中，但在运行时缓存它们。

还有一个页面使缓存无效，所以如果我们愿意，我们可以从管理页面更新数据库，然后使缓存无效，这样客户端就会在运行时获取新信息。这有助于配置正确的值以保持在 API 限制内并完成足够的工作。