HTTP状态代码429告诉发出请求的客户端回退，并在响应的Retry-After标头中指定的时间段后重试该请求。
在单线程客户端中，很明显，获取429的线程应按指示等待，然后重试。但是RFC明确指出
此规范未定义原始服务器如何识别 用户，以及如何计算请求。
因此，在多线程客户端中，保守的方法将阻止所有线程发送请求，直到Retry-After时间点为止。但是：
是否有人从现场获得云提供商的服务器如何实际处理的特定数据？如果我不全局限制所有线程，它们是否会立即恶化？ Microsoft's advice是
- 等待“重试后”字段中指定的秒数。
- 重试请求。
- 如果请求再次失败并显示429错误代码，则说明您仍然处于受限制状态。继续使用建议的Retry-After延迟，然后重试请求，直到成功为止。
它两次说“请求”而不是“任何请求”或“所有请求”，但这是我不敢相信的法律类型的解释。
为确保这不是一个意见问题，请允许我尽可能以事实为依据：
是否有关于云API的更详细的规范（Microsoft，Google，Facebook，Twitter），然后是上面的示例，它使我能够做出明智的决定，即是否有必要进行全局补偿，或者是否足以满足特定的要求。请求得到429？
答案 0 :(得分：0)
服务器知道其同步或希望程序员这样做。因此怀疑是否有处罚，除非他们收到大量请求，这些请求在429年后根本不撤消。
每个线程都应该等待，但是每个线程都需要等待，直到分别被告知。
一个好的系统会知道它的速率是多少，并且在其中。一种实现方法是在请求之间使用sleepFor变量。可以通过反复试验得出确切的prod值，它是睡眠时间减去先前的请求时间。
因此，如果一个请求结束，并说花费了x毫秒。现在，如果睡眠时间是 0以下，立即移至下一个请求 如果大于等于1，则发现sleepTime-x，如果小于1，则立即转到下一个，否则睡眠那么多毫秒，然后移至下一个请求。
另一种方法是每5分钟左右进行一次计数，然后，如果线程的实际请求数量超过该数量，则它将休眠直到5分钟为止，然后再移至下一个。这里可以将5设置为timePeriod。
我们要做的是将这些值保存在数据库中，但在运行时将其缓存。还有一个页面使缓存无效，因此，如果我们愿意，我们可以从管理页面更新数据库，然后使缓存无效，因此客户端将在运行时获取新信息。这有助于配置正确的值，使其不超出API限制并完成足够的工作。