目录

一. 前言

二. 配置（Configuration）

2.1. 处理者角色（Process Roles）

2.2. 控制器（controller）

2.3. 存储工具（Storage Tool）

2.4. 调试（Debugging）

2.4.1. 元数据选举工具（Metadata Quorum Tool）

2.4.2. 转储日志工具（Dump Log Tool）

2.4.3. 元数据指令（Metadata Shell）

2.5. 部署注意事项（Deploying Considerations）

2.6. 缺失的特性（Missing Features）

---

一. 前言

    目前，Kafka 在使用的过程当中，会出现一些问题。由于重度依赖 Zookeeper 集群，当Zookeeper 集群性能发生抖动时，Kafka 的性能也会收到很大的影响。因此，在 Kafka 发展的过程当中，为了解决这个问题，提供 KRaft 模式，来取消 Kafka 对 Zookeeper 的依赖。

二. 配置（Configuration）

2.1. 处理者角色（Process Roles）

原文引用：In KRaft mode each Kafka server can be configured as a controller, a broker, or both using the process.roles property. This property can have the following values:

• If process.roles is set to broker, the server acts as a broker.
• If process.roles is set to controller, the server acts as a controller.
• If process.roles is set to broker,controller, the server acts as both a broker and a controller.
• If process.roles is not set at all, it is assumed to be in ZooKeeper mode.

    在 KRaft 模式中，每个 Kafka 服务器都可以使用 process.roles 属性配置为 controller、broker 或这两个。此属性可以具有以下值：

• 如果 process.roles 设置为 broker，则服务器将充当 Broker。
• 如果 process.roles 设置为 controller，则服务器将充当 Controller。
• 如果 process.roles 设置为 broker,controller，则服务器同时充当 Broker 和 Controller。
• 如果根本没有设置 process.roles，则假定它处于 ZooKeeper 模式。

原文引用：Kafka servers that act as both brokers and controllers are referred to as "combined" servers. Combined servers are simpler to operate for small use cases like a development environment. The key disadvantage is that the controller will be less isolated from the rest of the system. For example, it is not possible to roll or scale the controllers separately from the brokers in combined mode. Combined mode is not recommended in critical deployment environments.

    同时充当 Broker 和 Controller 的 Kafka 服务器被称为“组合”服务器。对于像开发环境这样的小用例，组合服务器更易于操作。关键的缺点是控制器与系统的其余部分的隔离度较低。例如，在组合模式下，不可能将 Controller 与 Broker 程序分开滚动或缩放。不建议在关键部署环境中使用组合模式。

2.2. 控制器（controller）

原文引用：In KRaft mode, specific Kafka servers are selected to be controllers (unlike the ZooKeeper-based mode, where any server can become the Controller). The servers selected to be controllers will participate in the metadata quorum. Each controller is either an active or a hot standby for the current active controller.

    在 KRaft 模式中，特定的 Kafka 服务器被选择为控制器（与基于 ZooKeeper 的模式不同，在该模式中，任何服务器都可以成为控制器）。被选为控制器的服务器将参与元数据选举。每个控制器都是当前活动控制器的活动控制器或热备用控制器。

原文引用：A Kafka admin will typically select 3 or 5 servers for this role, depending on factors like cost and the number of concurrent failures your system should withstand without availability impact. A majority of the controllers must be alive in order to maintain availability. With 3 controllers, the cluster can tolerate 1 controller failure; with 5 controllers, the cluster can tolerate 2 controller failures.

    Kafka 管理员通常会为这个角色选择3到5台服务器，这取决于成本和系统在不影响可用性的情况下应该承受的并发故障数量等因素。为了保持可用性，大多数控制器必须是活动的。有3个控制器，集群可以容忍1个控制器故障；使用5个控制器，集群可以容忍2个控制器故障。

原文引用：All of the servers in a Kafka cluster discover the quorum voters using the controller.quorum.voters property. This identifies the quorum controller servers that should be used. All the controllers must be enumerated. Each controller is identified with their id, host and port information. For example: 

    Kafka 集群中的所有服务器都使用 controller.quorum.voters 属性来发现 quorum 投票者。这标识了应使用的选举控制器服务器。必须列举所有控制器。每个控制器都通过其 id、host 和 port 信息进行标识。例如：

controller.quorum.voters=id1@host1:port1,id2@host2:port2,id3@host3:port3

原文引用：If a Kafka cluster has 3 controllers named controller1, controller2 and controller3, then controller1 may have the following configuration:

    如果一个 Kafka 集群有三个控制器，分别命名为 controller1、controller2 和 controller3，那么controller1 可能具有以下配置：

process.roles=controller
node.id=1
listeners=CONTROLLER://controller1.example.com:9093
controller.quorum.voters=1@controller1.example.com:9093,2@controller2.example.com:9093,3@controller3.example.com:9093

原文引用：Every broker and controller must set the controller.quorum.voters property. The node ID supplied in the controller.quorum.voters property must match the corresponding id on the controller servers. For example, on controller1, node.id must be set to 1, and so forth. Each node ID must be unique across all the servers in a particular cluster. No two servers can have the same node ID regardless of their process.roles values.

    每个 Broker 和 Controller 都必须设置 controller.quorum.voters 属性。controller.quorum.voters属性中提供的节点 ID 必须与 Controller 服务器上的相应 ID 匹配。例如，在 controller1 上，node.id 必须设置为1，依此类推。在特定集群中的所有服务器中，每个节点 ID 都必须是唯一的。无论两台服务器的 process.role 值如何，都不能具有相同的节点 ID。

2.3. 存储工具（Storage Tool）

原文引用：The kafka-storage.sh random-uuid command can be used to generate a cluster ID for your new cluster. This cluster ID must be used when formatting each server in the cluster with the kafka-storage.sh format command.

    kafka-storage.sh random uuid 命令可用于为新集群生成集群 ID。使用 kafka-storage.sh format命令格式化群集中的每个服务器时，必须使用此群集 ID。

原文引用：This is different from how Kafka has operated in the past. Previously, Kafka would format blank storage directories automatically, and also generate a new cluster ID automatically. One reason for the change is that auto-formatting can sometimes obscure an error condition. This is particularly important for the metadata log maintained by the controller and broker servers. If a majority of the controllers were able to start with an empty log directory, a leader might be able to be elected with missing committed data.

    这与 Kafka 过去的运作方式不同。以前，Kafka 会自动格式化空白存储目录，并自动生成新的集群 ID。修改的一个原因是，自动格式化有时会模糊错误条件。这对于由 Controller 和 Broker 服务器维护的元数据日志来说尤其重要。如果大多数 Controller 能够从一个空的日志目录开始，则可能能够在缺少提交数据的情况下选出 Leader。

2.4. 调试（Debugging）

2.4.1. 元数据选举工具（Metadata Quorum Tool）

原文引用：The kafka-metadata-quorum tool can be used to describe the runtime state of the cluster metadata partition. For example, the following command displays a summary of the metadata quorum:

    Kafka kafka-metadata-quorum（元数据选举工具）可用于描述集群元数据分区的运行时状态。例如，以下命令显示元数据选举的摘要：

> bin/kafka-metadata-quorum.sh --bootstrap-server  broker_host:port describe --status
ClusterId:              fMCL8kv1SWm87L_Md-I2hg
LeaderId:               3002
LeaderEpoch:            2
HighWatermark:          10
MaxFollowerLag:         0
MaxFollowerLagTimeMs:   -1
CurrentVoters:          [3000,3001,3002]
CurrentObservers:       [0,1,2]

2.4.2. 转储日志工具（Dump Log Tool）

原文引用：The kafka-dump-log tool can be used to debug the log segments and snapshots for the cluster metadata directory. The tool will scan the provided files and decode the metadata records. For example, this command decodes and prints the records in the first log segment:

    Kafka kafka-dump-log（转储日志工具）可用于调试集群元数据目录的日志段和快照。该工具将扫描提供的文件并解码元数据记录。例如，此命令解码并打印第一个日志段中的记录：

> bin/kafka-dump-log.sh --cluster-metadata-decoder --files metadata_log_dir/__cluster_metadata-0/00000000000000000000.log

原文引用：This command decodes and prints the records in the a cluster metadata snapshot:

此命令解码并打印集群元数据快照中的记录：

> bin/kafka-dump-log.sh --cluster-metadata-decoder --files metadata_log_dir/__cluster_metadata-0/00000000000000000100-0000000001.checkpoint

2.4.3. 元数据指令（Metadata Shell）

原文引用：The kafka-metadata-shell tool can be used to interactively inspect the state of the cluster metadata partition:

Kafka kafka-metadata-shell（元数据外壳工具）可用于交互式检查集群元数据分区的状态：

> bin/kafka-metadata-shell.sh  --snapshot metadata_log_dir/__cluster_metadata-0/00000000000000000000.log
>> ls /
brokers  local  metadataQuorum  topicIds  topics
>> ls /topics
foo
>> cat /topics/foo/0/data
{"partitionId" : 0,"topicId" : "5zoAlv-xEh9xRANKXt1Lbg","replicas" : [ 1 ],"isr" : [ 1 ],"removingReplicas" : null,"addingReplicas" : null,"leader" : 1,"leaderEpoch" : 0,"partitionEpoch" : 0
}
>> exit

2.5. 部署注意事项（Deploying Considerations）

原文引用：

• Kafka server's process.role should be set to either broker or controller but not both. Combined mode can be used in development environments, but it should be avoided in critical deployment environments.
• For redundancy, a Kafka cluster should use 3 controllers. More than 3 controllers is not recommended in critical environments. In the rare case of a partial network failure it is possible for the cluster metadata quorum to become unavailable. This limitation will be addressed in a future release of Kafka.
• The Kafka controllers store all the metadata for the cluster in memory and on disk. We believe that for a typical Kafka cluster 5GB of main memory and 5GB of disk space on the metadata log director is sufficient.

• Kafka 服务器的 process.role 应该设置为 broker 或 controller，但不能同时设置。组合模式可以在开发环境中使用，但在关键部署环境中应避免使用。
• 对于冗余，一个 Kafka 集群应该使用3个 Controlloer。不建议在关键环境中使用3个以上的Controlloer。在极少数的部分网络故障情况下，群集元数据选举可能变得不可用。这一限制将在 Kafka 的未来版本中得到解决。
• Kafka Controller 将集群的所有元数据存储在内存和磁盘上。我们认为，对于典型的 Kafka 集群，元数据日志导向器上 5GB 的主内存和 5GB 的磁盘空间就足够了。

2.6. 缺失的特性（Missing Features）

原文引用：The following features are not fully implemented in KRaft mode:

• Supporting JBOD configurations with multiple storage directories
• Modifying certain dynamic configurations on the standalone KRaft controller
• Delegation tokens

以下功能未在 KRaft 模式中完全实现：

• 支持具有多个存储目录的 JBOD 配置。
• 修改独立 KRaft 控制器上的某些动态配置。
• 委派令牌。