kafka配额

半兽人 发表于: 2017-01-07   最后更新时间: 2017-12-24  
  •   267 订阅,6429 游览

4.9 配额

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

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

  1. 通过配额定义网络带宽的字节率阈值(从0.9版本开始)
  2. 请求率配额将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个窗口)导致大量的流量突发,随后引起长时间的延迟,这在用户体验方面不好。







发表于: 1年前   最后更新时间: 6月前   游览量:6429
上一条: kafka日志压缩
下一条: kafka接口设计

评论…


  • 如果(user=“test=user”,client-id="test-client")
    这里有个小错误哦,应该是user="test-user"
  • 评论…
    • in this conversation
      提问