我要评论目录
2.4.1. 元数据选举工具（metadata quorum tool）
2.5. 部署注意事项（deploying considerations）
一. 前言
目前，kafka 在使用的过程当中，会出现一些问题。由于重度依赖 zookeeper 集群，当zookeeper 集群性能发生抖动时，kafka 的性能也会收到很大的影响。因此，在 kafka 发展的过程当中，为了解决这个问题，提供 kraft 模式，来取消 kafka 对 zookeeper 的依赖。
二. 配置（configuration）
2.1. 处理者角色（process roles）
在 kraft 模式中，每个 kafka 服务器都可以使用 process.roles 属性配置为 controller、broker 或这两个。此属性可以具有以下值：
- 如果 process.roles 设置为 broker，则服务器将充当 broker。
- 如果 process.roles 设置为 controller，则服务器将充当 controller。
- 如果 process.roles 设置为 broker,controller，则服务器同时充当 broker 和 controller。
- 如果根本没有设置 process.roles，则假定它处于 zookeeper 模式。
同时充当 broker 和 controller 的 kafka 服务器被称为“组合”服务器。对于像开发环境这样的小用例，组合服务器更易于操作。关键的缺点是控制器与系统的其余部分的隔离度较低。例如，在组合模式下，不可能将 controller 与 broker 程序分开滚动或缩放。不建议在关键部署环境中使用组合模式。
2.2. 控制器（controller）
在 kraft 模式中，特定的 kafka 服务器被选择为控制器（与基于 zookeeper 的模式不同，在该模式中，任何服务器都可以成为控制器）。被选为控制器的服务器将参与元数据选举。每个控制器都是当前活动控制器的活动控制器或热备用控制器。
kafka 管理员通常会为这个角色选择3到5台服务器，这取决于成本和系统在不影响可用性的情况下应该承受的并发故障数量等因素。为了保持可用性，大多数控制器必须是活动的。有3个控制器，集群可以容忍1个控制器故障；使用5个控制器，集群可以容忍2个控制器故障。
kafka 集群中的所有服务器都使用 controller.quorum.voters 属性来发现 quorum 投票者。这标识了应使用的选举控制器服务器。必须列举所有控制器。每个控制器都通过其 id、host 和 port 信息进行标识。例如：
controller.quorum.voters=id1@host1:port1,id2@host2:port2,id3@host3:port3如果一个 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每个 broker 和 controller 都必须设置 controller.quorum.voters 属性。controller.quorum.voters属性中提供的节点 id 必须与 controller 服务器上的相应 id 匹配。例如，在 controller1 上，node.id 必须设置为1，依此类推。在特定集群中的所有服务器中，每个节点 id 都必须是唯一的。无论两台服务器的 process.role 值如何，都不能具有相同的节点 id。
2.3. 存储工具（storage tool）
kafka-storage.sh random uuid 命令可用于为新集群生成集群 id。使用 kafka-storage.sh format命令格式化群集中的每个服务器时，必须使用此群集 id。
这与 kafka 过去的运作方式不同。以前，kafka 会自动格式化空白存储目录，并自动生成新的集群 id。修改的一个原因是，自动格式化有时会模糊错误条件。这对于由 controller 和 broker 服务器维护的元数据日志来说尤其重要。如果大多数 controller 能够从一个空的日志目录开始，则可能能够在缺少提交数据的情况下选出 leader。
2.4. 调试（debugging）
2.4.1. 元数据选举工具（metadata quorum tool）
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）
kafka kafka-dump-log（转储日志工具）可用于调试集群元数据目录的日志段和快照。该工具将扫描提供的文件并解码元数据记录。例如，此命令解码并打印第一个日志段中的记录：
> bin/kafka-dump-log.sh --cluster-metadata-decoder --files metadata_log_dir/__cluster_metadata-0/00000000000000000000.log此命令解码并打印集群元数据快照中的记录：
> bin/kafka-dump-log.sh --cluster-metadata-decoder --files metadata_log_dir/__cluster_metadata-0/00000000000000000100-0000000001.checkpoint2.4.3. 元数据指令（metadata shell）
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
}
>> exit2.5. 部署注意事项（deploying considerations）
- kafka 服务器的 process.role 应该设置为 broker 或 controller，但不能同时设置。组合模式可以在开发环境中使用，但在关键部署环境中应避免使用。
- 对于冗余，一个 kafka 集群应该使用3个 controlloer。不建议在关键环境中使用3个以上的controlloer。在极少数的部分网络故障情况下，群集元数据选举可能变得不可用。这一限制将在 kafka 的未来版本中得到解决。
- kafka controller 将集群的所有元数据存储在内存和磁盘上。我们认为，对于典型的 kafka 集群，元数据日志导向器上 5gb 的主内存和 5gb 的磁盘空间就足够了。
2.6. 缺失的特性（missing features）
以下功能未在 kraft 模式中完全实现：
- 支持具有多个存储目录的 jbod 配置。
- 修改独立 kraft 控制器上的某些动态配置。
- 委派令牌。
发表评论