Doorman是全球分布式客户端速率限制的解决方案。与共享资源（例如数据库、gRPC服务、RESTful API或其他资源）通信的客户端可以使用Doorman自愿限制其使用资源的方式（通常是每秒请求数）。Doorman是用Go编写的，并使用gRPC作为其通信协议。对于某些高可用性功能，它需要分布式锁管理器。我们目前支持etcd，但是使用Zookeeper代替应该相对简单。
入门指南
Doorman的目的是根据某种公平的定义，分配和分发客户端的容量。客户端获得资源的容量取决于以下四个因素：
- 资源(全球范围内)的配置最大容量。
- 此客户端的容量需求(希望)。
- 全球所有其他客户端的容量需求(希望)。
- 用于在所有客户端之间分配容量的确切算法(由配置定义)。
Doorman主服务器会记住当前具有容量的所有客户端，并在客户端请求容量时将其请求插入其内存并运行算法，以确定此客户端应该获得什么。
租约长度和刷新间隔
Doorman只在有限的时间内分配容量，以租约形式给出。每个容量授予都带有租约长度：客户端在租约期间保证获得相应的容量。典型的租约长度为五分钟。除了租约长度之外，Doorman服务器还返回刷新间隔。这是客户端预计多长时间后需要重新检查以获取新租约的间隔。典型的刷新间隔为五秒。
注意：Doorman系统是合作性的。客户端应该遵守容量授予、租约长度和刷新间隔。该系统没有保护不良行为的客户端。
在系统的正常操作中，所有客户端都定期向服务器检查以刷新其容量。服务器知道所有客户端及其资源需求，并在每个请求上对容量进行最佳分配。出于优化目的(减少Doorman服务器上的qps)，客户端代码会在向Doorman服务器发送请求时进行所有资源的批量刷新。这意味着在特定情况下（例如注册新资源时），资源可能会比预期更快地刷新其容量。
Doorman配置指定了应使用哪个算法将容量分配给所有客户端。算法页面解释了当前可用的算法及其如何将容量分配给每个客户端。
租约长度和刷新间隔这两个参数优化了系统的多种不同行为：
- Doorman服务器的负载。
- 系统在资源需求变化和客户端出现和消失时收敛的速度。
- 系统如何处理Doorman服务器无法访问或响应缓慢。
当Doorman服务器变得无法访问并重新连接时。
当客户端无法访问Doorman服务器时，以下情况发生：
- 客户端会错过一个或多个刷新间隔。对于客户端来说，这并不重要，只是客户端的容量不会因为潜在的资源需求变化而调整。
- 当Doorman服务器长时间不可用时，租约会过期，资源会恢复到其配置的安全容量。这可以是以下任何一个：
- 1，表示无界（无限）速率限制，或
- 0，表示所有对资源的访问都被阻止，或者是一个正数。
- 一旦Doorman服务器重新可达，客户端将恢复请求容量。
注意：Doorman在不同集群中使用多个服务器和主选举过程来确定当前的主服务器。
Doorman不共享或存储其内部数据库。这意味着当Doorman服务器成为主服务器时，它会从空的客户端和未完成的租约仓库开始。但是这并不像看起来的那么严重，因为一旦服务器可用，所有客户端都会开始调用它以刷新其租约。由于Doorman服务器知道它没有足够的信息来运行其算法，因此它将简单地返回当前分配的容量，或者如果请求来自当前没有资源容量的客户端，则返回零。服务器知道当前分配的容量，因为客户端在每个GetCapacity RPC中都会包含它。这个阶段的服务器被称为学习模式。
在资源的学习模式期间，每个请求都将被回答一个相同容量的新租约。实际上，在几个刷新间隔之后，服务器可以合理地确定它已经与所有现有的客户端联系过了。然而，出于安全原因，缺省的学习模式持续时间与租约长度相同。这个决定确保当学习模式持续时间到期时，我们可以确定没有租约是我们不知道的（因为这些租约已经过期）。如果你想在Doorman主节点选举后更快地收敛系统，你可以在资源模板中显式配置学习模式持续时间（有关更多信息，请参见系统配置页面）。
谁想要什么？
Doorman 要求客户端告知其所需的容量（即所谓的“希望”）。如果您使用低级别的 Doorman 客户端，则需要确定您的容量需求并调用适当的方法，以确保在其刷新周期内客户端库请求该容量量级的容量。但是，如果您使用 Doorman 客户端提供的速率限制器对象，则通过观察想要访问资源的线程的行为，自动确定所需的容量。这种自动希望确定使用移动平均值来平滑任何波动。