...

1. Quota configuration for user principal. This prevents users generating heavy traffic from monopolizing resources and impacting the performance of other users in a multi-tenant cluster.
2. Quota overrides for clients of an authenticated user.  Like the current client-id implementation, this enables a user to rate-limit some producers or consumers to ensure that they don’t impact other more critical clients.  For instance, users may be able to rate-limit an auditing client running in the background, leaving resources always available for a critical event processing client.
3. Client-id quotas for users without a user quota override. Existing quota configuration for client-ids will continue to be applied to users with unlimited quota, but these will be applied as per-user quota for clients that share both user principal and client-id.Shared quotas for groups of clients that span multiple users will no longer be supportedif no user-specific defaults are configured. Defaults may also be specified for client-ids that do not span multiple users.

The goal of this KIP is to provide a single unified quota implementation with a simple configuration for client-id based quotas, a similar simple configuration for user quotas and the flexibility to define more complex quota configurations.

...

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

Quota Entity

1. /config/clients/<client-id>
2. /config/clients

Quota Entity

Quotas Quotas are currently configured for client-ids. All clients with the same client-id are currently grouped together as a quota entity, enforcing one quota for all clients with the same client-id. This KIP proposes to define quotas for safe client groups which share the same user-principal and client-id . In a single user cluster, this retains the current semantics of and user-level quotas that limit the total quota of users in addition to the existing client-id quotas.

Configuration Options

...

quota.producer.default, quota.consumer.default: Default client-id producer/consumer quota  is currently applied to each unique client-id across all users. This will be modified to be a per-user quota for each unique client-id of each user. This client-id default will is be applied only if default user quota is unlimited . and no user-specific defaults are configured. These properties will be deprecated and will be applied only if dynamic default quotas are not configured for clients.

...

• Default user quota will be stored in Zookeeper at the top level config for /config/users. If not specified, user quota will be unlimited and and <user, client-id id> defaults will apply. Default user quota can be updated dynamically.
• Default quota for <user, client-id> will be stored in/config/users/<default>/clients. If not specified, client-id defaults will apply.
• Default client-id quota will be stored in Zookeeper at the top level config for /config/clients. If not specified, the broker properties quota.producer.default, quota.consumer.default will be used as the default client-id quota for clients of users with unlimited quota.

...

Quota related metrics are currently generated for client-ids and use the tag tag "client-id. The metrics tag will be changed to quota-id and the value will include base-64 encoded user principal". URL-encoded user principal will be added with the tag "user". Both user and client-id tags will be specified when <user, client-id> quotas are applied, only user tag will be specified if user quota is applied and the existing client-id tag will be retained if client-id quotas are applied.

Sensor names are currently a sensor type concatenated with the client id value, eg. FetchThrottleTime-clientA. This will be modified to use quota-id instead of client-id. This is not a public interface change since sensor names are not reflected in JMX metrics.

...

Default quotas for users or clients or <user, client-id> can be configured by omitting entity name. For example:

...

1. If quota override is defined for <userN, clientX> in /config/users/userN/clients/clientX, this quota is allocated for the sole use of <userN, clientX>.
2. If user quota override is defined for userN, clientX in /config/users/userN shares this quota with other clients of userN
3. If default user quota is defined in /config/users, clientX shares this default quota with other clients of userN
4. If <user, client-id id> quota override is defined for clientX in /config/users/clients<default>clients/clientX, this quota is allocated for the sole use of <userN, clientX>
5. If dynamic default <user, client-id default id> quota is configured defined in /config/users/clients<default>clients, this default quota is allocated for the sole use of <userN, clientX>
6. If client-id quota override is defined for clientX in /config/clients/clientX, this quota is shared across client-id <clientX> of all users
   
7. If dynamic client-id default is configured in /config/clients, this default quota is shared across client-id <clientX> of all users
8. If quota.producer.default is configured for the broker in server.properties, this is shared across client-id <clientX> of all users quota.producer.default is configured for the broker in server.properties, this default quota is allocated for the sole use of <userN, clientX>
9. Client is not throttled

Use cases:

• Simple client-id based quotas are configured using client-id quota override, dynamic client-id default and static quota.producer.default : (steps 4steps  6, 57, 68, 79)

• Simple user-principal based quotas are configured using user quota override and user quota default : (steps 2, 3, 79)
• More specific <user, client-id> quotas and defaults for users and client-ids can be configured if required: (steps 1 - 79)

// Default user quota
// Zookeeper persistence path /users
{
    "version":1,
    "config": {
        "producer_byte_rate":"10000",
        "consumer_byte_rate":"20000"
    }
}

...

1. Total rate limits for all clients with user principal user1 is (1024, 2048).
2. Total rate limits for all clients with user principal user2 without additional client-id quota is (4096, 8192).
   
   • The rate limits for clients with user principal user2 AND client-id clientA is (10, 20).
   • Clients of user2 with client-id other than clientA and clientB share the quota (4096, 8192).
3. Total rate limits for all clients of user3  is the default (10000, 20000), since no config override is specified.
4. If default user quota is not specified or is unlimited, clients of user3 use client-id quota configuration. For example quota for client-id clientA of user3 is (100, 200) and this is shared with clients of other users with client-id clientA. And quota for client-id clientB of user3 without a client-id override is (quota.producer.default, quota.consumer.default)
   • In a singlemulti-user cluster, this provides the same semantics as the current client-id implementationIn a multi-user cluster,  quotas are now per-user, treating clientA of user4 as a different   defaults can also be specified for <user, client-id> quotas  which treat clientA of user4 as a different group from clientA of user2.

Quota Identifier

Quota configuration and metrics sensors currently use client-id as the unique key, enforcing one quota for all clients with the same client-id. This will be replaced with a new quota-id that includes user principal. Each quota-id is associated with a pair of producer and consumer rate limits which may be config overrides or the default quota.

• quota-id is the concatenation of url-encoded user principal and client-id . Clients-ids without a quota override share the user's quota and hence use for <user, client-id> quota, just the client-id for client-id quotas and just the encoded user principal as for user quotas. Similarly, quota-id.related metrics names will include the tags client-id and/or user.
• In the exampleIn the example (non-encoded user principal is used here for readability):
  • All clients of user1 share the quota-id user1:
  • clientA of user2 uses the quota-id user2clientA user2:clientA
  • clientC of user2 uses the quota-id user2: since it does not have a client quota override, sharing a quota with other clients of user2.
  • clientA of user3 uses the quota-id user3clientA :clientA

Quota Persistence in Zookeeper

...

No client API changes are necessary to work with the new implementation. Existing client-id quota configuration will be processed from Zookeeper and since users have unlimited quota as default,  existing client-id quotas will be applied to all clients with the client-id. In a PLAINTEXT or single-user cluster, this provides the same semantics as now, but in a multi-user cluster, quotas will be applied per-user rather than across users.  For multi-user clusters that are currently using client-id rate limits, new per-user rate limits should be configured first before upgrading the cluster if shared rate limits are being used for clients of different users.

Rejected Alternatives

Broker configuration property to choose either client-id or user quota

...