除非有必要，否则不要重复发明轮子。检查一下ratelimit库。如果你只是出于某种原因想限制你对rest api的调用，然后继续你的生活，那么它是完美的。

from datetime import timedelta
from ratelimit import limits, sleep_and_retry
import requests

@sleep_and_retry
@limits(calls=1, period=timedelta(seconds=60).total_seconds())
def get_foobar():
    response = requests.get('https://httpbin.org/get')
    response.raise_for_status()
    return response.json()

如果发出的请求数超过每分钟一个，这将“阻塞"线程。

使用队列和调度程序时效果更好。
您将处理分为两部分：source和dispatch。它们可以是单独的线程（或者是单独的进程，如果更容易的话）。

Source端以任何让它们满意的速率创建请求并将其入队。
调度端执行此操作。

1.获取请求开始时间 s。
1.将请求出列，通过远程服务处理请求。
1.获取当前时间 t。休眠 rate -（t - s）秒。
如果你想运行直接连接到远程服务的Source端，你可以这样做，并绕过速率限制。这对于使用远程服务的模拟版本进行内部测试是很好的。
困难的部分是为每个可以排队的请求创建一些表示，因为Python Queue可以处理几乎所有的事情，所以你不需要做太多。
如果使用多处理，则必须对对象进行pickle操作，才能将它们放入管道中。

排队可能过于复杂。一个简单的解决方案是为类提供一个变量，表示上次调用服务的时间。每当调用服务时（！1），请将waitTime设置为delay - Now + lastcalltime。delay应等于请求之间允许的最小时间。如果此数字为正数，在进行调用（！2）之前休眠那么长时间。这种方法的缺点/优点是它将Web服务请求视为同步的。优点是它非常简单并且易于实现。

• （！1）：应该在 Package 函数内（可能在 Package 函数的底部）收到服务的回应之后立即发生。
• （！2）：应该在调用Web服务周围的python Package 器时发生，位于 Package 器的顶部。

当然，S.Lott的解决方案更为优雅。

您的速率限制方案应该受到底层代码的调用约定（同步或异步）以及此速率限制将在什么范围（线程、进程、计算机、集群？）内操作的严重影响。
我建议将所有变量都保留在示例中，这样您就可以轻松地实现多个周期/比率的控制。
最后，听起来你想成为一个中间件组件。不要试图成为一个应用程序，自己引入线程。如果你是同步的，就阻塞/休眠，如果你被其中一个调用，就使用异步调度框架。

如果您的库被设计为同步的，那么我建议忽略限制的实施（尽管您可以跟踪速率并至少帮助调用者决定如何荣誉限制）。
现在我使用twisted来与几乎所有的东西接口。它通过一个将请求提交与响应处理分离的模型来使这类事情变得容易。如果你不希望你的API用户不得不使用twisted，你至少最好了解他们的延迟执行API。
例如，我有一个twitter接口，它代表xmpp users推送了相当多的请求，我没有速率限制，但我确实必须做一些工作来防止所有请求同时发生。

因此，我假设一些简单的东西，如导入时间time.sleep（2）将无法在请求之间等待2秒