目录

一. 前言

二. Kafka 多租架构（Multi-Tenancy）

2.1. 概览

2.2. 使用 Topic 命名为租户创建用户空间（命名空间）

2.3. 配置 Topic（Configuring Topics: Data Retention And More）

---

一. 前言

    Kafka 租户模式是一种多租户架构模式，用于在单个 Kafka 集群中支持多个不同的租户。这种模式可以提供更好的资源隔离和租户管理，同时减少硬件成本和管理复杂性。

二. Kafka 多租架构（Multi-Tenancy）

2.1. 概览

原文引用：As a highly scalable event streaming platform, Kafka is used by many users as their central nervous system, connecting in real-time a wide range of different systems and applications from various teams and lines of businesses. Such multi-tenant cluster environments command proper control and management to ensure the peaceful coexistence of these different needs. This section highlights features and best practices to set up such shared environments, which should help you operate clusters that meet SLAs/OLAs and that minimize potential collateral damage caused by "noisy neighbors".

    作为一个高度可扩展的事件流媒体平台，Kafka 被许多用户用作他们的中枢神经系统，实时连接来自不同团队和业务线的各种不同系统和应用程序。这种多租户集群环境需要适当的控制和管理，以确保这些不同需求可以和平共处。本节重点介绍了设置此类共享环境的功能和最佳实践，这些功能和实践将有助于您运营符合 SLAs/OLAs 的集群，并最大限度地减少“嘈杂邻居”造成的潜在附带损害。

原文引用：Multi-tenancy is a many-sided subject, including but not limited to:

• Creating user spaces for tenants (sometimes called namespaces)
• Configuring topics with data retention policies and more
• Securing topics and clusters with encryption, authentication, and authorization
• Isolating tenants with quotas and rate limits
• Monitoring and metering
• Inter-cluster data sharing (cf. geo-replication)

多租户是一个多方面的主题，包括但不限于：

• 为租户创建用户空间（有时称为命名空间）。
• 使用数据保留策略等配置 Topic。
• 通过加密、身份验证和授权保护 Topic和集群。
• 用配额和速率限制隔离租户。
• 监测和计量。
• 集群间数据共享（参见地理复制）。

2.2. 使用 Topic 命名为租户创建用户空间（命名空间）

原文引用：Kafka administrators operating a multi-tenant cluster typically need to define user spaces for each tenant. For the purpose of this section, "user spaces" are a collection of topics, which are grouped together under the management of a single entity or user.

    操作多租户集群的 Kafka 管理员通常需要为每个租户定义用户空间。就本节而言，“用户空间”是Topic 的集合，在单个实体或用户的管理下分组在一起。

原文引用：In Kafka, the main unit of data is the topic. Users can create and name each topic. They can also delete them, but it is not possible to rename a topic directly. Instead, to rename a topic, the user must create a new topic, move the messages from the original topic to the new, and then delete the original. With this in mind, it is recommended to define logical spaces, based on an hierarchical topic naming structure. This setup can then be combined with security features, such as prefixed ACLs, to isolate different spaces and tenants, while also minimizing the administrative overhead for securing the data in the cluster.

    在 Kafka 中，数据的主要单位是 Topic。用户可以创建并命名每个 Topic。他们也可以删除它们，但不能直接重命名 Topic。相反，要重命名 Topic，用户必须创建一个新 Topic，将消息从原始 Topic 移动到新 Topic，然后删除原始 Topic。考虑到这一点，建议基于分层 Topic 命名结构定义逻辑空间。然后，可以将此设置与安全功能（如带前缀的 ACLs）相结合，以隔离不同的空间和租户，同时最大限度地减少保护集群中数据的管理开销。

原文引用：These logical user spaces can be grouped in different ways, and the concrete choice depends on how your organization prefers to use your Kafka clusters. The most common groupings are as follows.

    这些逻辑用户空间可以以不同的方式分组，具体的选择取决于您的组织喜欢如何使用 Kafka 集群。最常见的分组如下。

原文引用：By team or organizational unit: Here, the team is the main aggregator. In an organization where teams are the main user of the Kafka infrastructure, this might be the best grouping.

    按团队或组织单位：在这里，团队是主要的聚合器。在一个团队是 Kafka 基础设施的主要用户的组织中，这可能是最好的分组。

原文引用：Example topic naming structure:

• <organization>.<team>.<dataset>.<event-name> (e.g., "acme.infosec.telemetry.logins")

Topic 命名结构示例：

• <organization>.<team>.<dataset>.<event-name>（例如，“acme.infosec.termetry.logins”）

原文引用：By project or product: Here, a team manages more than one project. Their credentials will be different for each project, so all the controls and settings will always be project related.

    按项目或产品：在这里，一个团队管理多个项目。每个项目的凭据都不同，因此所有控件和设置始终与项目相关。

原文引用：Example topic naming structure:

• <project>.<product>.<event-name> (e.g., "mobility.payments.suspicious")

Topic 命名结构示例：

• <project>.<product>.<event-name>（例如，“mobility.payments.suspicious”）

原文引用：Certain information should normally not be put in a topic name, such as information that is likely to change over time (e.g., the name of the intended consumer) or that is a technical detail or metadata that is available elsewhere (e.g., the topic's partition count and other configuration settings).

    某些信息通常不应放在 Topic 名称中，例如可能随时间变化的信息（例如，预期消费者的名称），或者是其他地方可用的技术细节或元数据（例如，Topic 的分区计数和其他配置设置）。

原文引用：To enforce a topic naming structure, several options are available:

• Use prefix ACLs (cf. KIP-290) to enforce a common prefix for topic names. For example, team A may only be permitted to create topics whose names start with payments.teamA..
• Define a custom CreateTopicPolicy (cf. KIP-108 and the setting create.topic.policy.class.name) to enforce strict naming patterns. These policies provide the most flexibility and can cover complex patterns and rules to match an organization's needs.
• Disable topic creation for normal users by denying it with an ACL, and then rely on an external process to create topics on behalf of users (e.g., scripting or your favorite automation toolkit).
• It may also be useful to disable the Kafka feature to auto-create topics on demand by setting auto.create.topics.enable=false in the broker configuration. Note that you should not rely solely on this option. 

要强制主题命名结构，有几个选项可用：

• 使用前缀 ACLs（参见 KIP-290）为 Topic 名称强制使用通用前缀。例如，团队 A 可能只被允许创建名称以支付开头的 Topic。
• 定义一个自定义的 CreateTopicPolicy（参见 KIP-108 和设置 create.topic.policy.class.name）以强制执行严格的命名模式。这些策略提供了最大的灵活性，可以覆盖复杂的模式和规则，以满足组织的需求。
• 通过 ACL 拒绝为普通用户创建 Topic，然后依靠外部进程代表用户创建 Topic（例如，脚本或您喜欢的自动化工具包）。
• 通过在 Broker 配置中设置 auto.create.topics.enable=false，禁用 Kafka 功能以根据需要自动创建 Topic 也可能很有用。请注意，您不应仅依赖此选项。

2.3. 配置 Topic（Configuring Topics: Data Retention And More）

原文引用：Kafka's configuration is very flexible due to its fine granularity, and it supports a plethora of per-topic configuration settings to help administrators set up multi-tenant clusters. For example, administrators often need to define data retention policies to control how much and/or for how long data will be stored in a topic, with settings such as retention.bytes (size) and retention.ms (time). This limits storage consumption within the cluster, and helps complying with legal requirements such as GDPR.

    Kafka 的配置由于其精细的粒度而非常灵活，并且它支持过多的每个 Topic 的配置设置，以帮助管理员设置多租户集群。例如，管理员通常需要定义数据保留策略，以控制主题中数据的存储量和/或存储时间，设置如 retention.bytes（大小）和 retention.ms（时间）。这限制了集群中的存储消耗，并有助于遵守 GDPR 等法律要求。

后续内容请参见《（二）Kafka 多租户架构》。