4.9 配额

从0.9开始，Kafka集群能够对生产和消费设置配额。为每个客户端分组设置配额阈值（基于字节比率）。

Kafka集群有能力对请求进行配额来控制客户端使用的broker资源。可以为共享配额的每个客户组执行两种类型的客户配额：

通过配额定义网络带宽的字节率阈值（从0.9版本开始）
请求率配额将CPU的利用率阈值定义为网络和I/O线程的百分比（自0.11版本起）

为什么需要配额？

生产者和消费者的可能生产/消费非常大量的数据，从而垄断了broker的资源，引起网络饱和，配额可防止这个问题。在大型多节点集群中更加重要。其中有一小部分不良行为的用户将被降权。事实上，当kafka作为服务运行时，可以根据约定好的协议执行API限制。

客户端集群

在安全的集群中，Kafka客户端通过已认证的用户的principal来标识的。在一个无需认证客户端的集群中，用户principal是一个未认证的分组。用户的principal是通过broker（使用可配置的PrincipalBuilder）。Client-id是客户端应用程序使用具有意义名称的客户端的逻辑分组。元组（user，client-id）定义了共享用户principal和client-id的客户端安全逻辑分组。

配额可以应用到（user，client-id），用户或clinet-id组中。为了一个给定的连接，应用与连接匹配的最具体的配额。所有的配额分组的连接
共享配置的分组配额。例如，如果（user=“test-user”,client-id="test-client"）生产配额是10MB/sec，那么将会应用到所有生产者用户是“test-user”和clinet-id“是test-client”的实例上。

配额配置

为user和client-id分组定义配额配置。可根据自身需要去覆盖默认的配置，这个机制类似于topic日志配置覆盖。用户和（user, client-id）配额覆盖写在ZooKeeper的/config/users下,client-id配额覆盖写在/config/clients下。这些配置被所有broker读取，并立即生效。并且我们更改配置而无需重启整个集群。点击这里查看更多细节。每个分组默认的配额也可使用相同的机制来动态地更新。

配额配置的优先级顺序为：

1.
 /config
/users/
<
user
>
/clients/
<
client-id
>
2.
 /config
/users/
<
user
>
/clients/
<
default
>
3.
 /config
/users/
<
user
>
4.
 /config
/users/
<
default
>
/clients/
<
client-id
>
5.
 /config
/users/
<
default
>
/clients/
<
default
>
6.
 /config
/users/
<
default
>
7.
 /config
/clients/
<
client-id
>
8.
 /config
/clients/
<
default
>

可以通过Broker配置（quota.producer.default, quota.consumer.default）为client-id分组设置默认的网络带宽配额。但已不赞成使用，并将在后面的版本移除。client-id的默认的配额可以在zookeeper设置（类似其他的配额覆盖和默认）。

网络带宽配额

网络带宽配额被定义为的字节速率阈值（客户端的每个分组共享的配额）。默认情况下，每个独立的客户端分组按照集群的配置接收固定的配额（字节/秒）。这个配额是基于每个broker上的定义。每个客户端分组在客户端被限制之前发布/获取每个broker的最大X字节/秒。

请求的比率配额

请求比率配额定义为一个客户端可以请求利用配额窗口中的每个broker的请求处理I/O线程和网络线程的时间百分比。n%的配额代表一个线程的n%，因此配额超出 ((num.io.threads + num.network.threads) * 100)%的总容量。在限制之前，每个客户端分组可能在配额窗口的所有I/O和网络线程使用高达n%的总百分比。由于分配给I/O和网络线程的线程数通常基于broker主机上可用的核心数量（CPU核心数），所以请求率配额代表共享配额的每组客户端可能使用的CPU的总百分比。

强制执行

默认情况下，每个独立的客户端分组接收一个固定的配额（集群配置的）。该配额基于每个broker定义的。每个客户端在被限制之前都使用该配额。我们决定，为每个broker定义的这些配额比固定的集群带宽要好得多，因为需要一个机制在所有broker中共享客户端配额。这可能比配额实现本身更难！

当检测到配额违规时，broker该做出什么样的反应？在我们的解决方案中，broker不返回错误，而是尝试减慢超出其配额的客户端。它计算延迟量，使违规的客户端根据其配额并延迟该时段的响应时间。这个方法保持对客户端违法配额透明（除client度量）。这也使他们不必实现任何特殊的回退或重试（否则可能会变得很麻烦）。事实上，坏的客户端行为（不重试回退）可能加速尝试解决的配额问题。

字节率和线程利用率是通过多个小窗口（例如每个1秒的30个窗口）来测量，以便快速检测和纠正配额违规。通常，具有大的测量窗口（例如，每个30秒的10个窗口）导致大量的流量突发，随后引起长时间的延迟，这在用户体验方面不好。

配额