Kafka设计解析：Replication工具

最新推荐文章于 2023-05-21 19:33:15 发布
最新推荐文章于 2023-05-21 19:33:15 发布
阅读量785 收藏
点赞数
分类专栏： kafka 文章标签： kafka

Topic Tool

　　$KAFKA_HOME/bin/kafka-topics.sh，该工具可用于创建、删除、修改、查看某个Topic，也可用于列出所有Topic。另外，该工具还可修改某个Topic的以下配置。

unclean.leader.election.enable
delete.retention.ms
segment.jitter.ms
retention.ms
flush.ms
segment.bytes
flush.messages
segment.ms
retention.bytes
cleanup.policy
segment.index.bytes
min.cleanable.dirty.ratio
max.message.bytes
file.delete.delay.ms
min.insync.replicas
index.interval.bytes
Replica Verification Tool

　　$KAFKA_HOME/bin/kafka-replica-verification.sh，该工具用来验证所指定的一个或多个Topic下每个Partition对应的所有Replica是否都同步。可通过topic-white-list这一参数指定所需要验证的所有Topic，支持正则表达式。

Preferred Replica Leader Election Tool

用途

　　有了Replication机制后，每个Partition可能有多个备份。某个Partition的Replica列表叫作AR（Assigned Replicas），AR中的第一个Replica即为“Preferred Replica”。创建一个新的Topic或者给已有Topic增加Partition时，Kafka保证Preferred Replica被均匀分布到集群中的所有Broker上。理想情况下，Preferred Replica会被选为Leader。以上两点保证了所有Partition的Leader被均匀分布到了集群当中，这一点非常重要，因为所有的读写操作都由Leader完成，若Leader分布过于集中，会造成集群负载不均衡。但是，随着集群的运行，该平衡可能会因为Broker的宕机而被打破，该工具就是用来帮助恢复Leader分配的平衡。

　　事实上，每个Topic从失败中恢复过来后，它默认会被设置为Follower角色，除非某个Partition的Replica全部宕机，而当前Broker是该Partition的AR中第一个恢复回来的Replica。因此，某个Partition的Leader（Preferred Replica）宕机并恢复后，它很可能不再是该Partition的Leader，但仍然是Preferred Replica。

原理

　　1. 在ZooKeeper上创建/admin/preferred_replica_election节点，并存入需要调整Preferred Replica的Partition信息。
　　2. Controller一直Watch该节点，一旦该节点被创建，Controller会收到通知，并获取该内容。
　　3. Controller读取Preferred Replica，如果发现该Replica当前并非是Leader并且它在该Partition的ISR中，Controller向该Replica发送LeaderAndIsrRequest，使该Replica成为Leader。如果该Replica当前并非是Leader，且不在ISR中，Controller为了保证没有数据丢失，并不会将其设置为Leader。

用法

1 $KAFKA_HOME/bin/kafka-preferred-replica-election.sh --zookeeper www.iteblog.com:2181

在包含8个Broker的Kafka集群上，创建1个名为topic1，replication-factor为3，Partition数为8的Topic，使用如下命令查看其Partition/Replica分布。

1 $KAFKA_HOME/bin/kafka-topics.sh --describe --topic iteblog --zookeeper www.iteblog.com:2181

查询结果如下图所示，从图中可以看到，Kafka将所有Replica均匀分布到了整个集群，并且Leader也均匀分布:

Topic:iteblog	PartitionCount:8	ReplicationFactor:1	Configs:
	Topic: iteblog	Partition: 0	Leader: 1	Replicas: 1,3,4	Isr: 4,1,3
	Topic: iteblog	Partition: 1	Leader: 2	Replicas: 2,4,5	Isr: 5,2,4
	Topic: iteblog	Partition: 2	Leader: 3	Replicas: 3,5,6	Isr: 5,3,6
	Topic: iteblog	Partition: 3	Leader: 4	Replicas: 4,6,7	Isr: 4,7,6
	Topic: iteblog	Partition: 4	Leader: 5	Replicas: 5,7,0	Isr: 5,7,0
	Topic: iteblog	Partition: 5	Leader: 6	Replicas: 6,0,1	Isr: 0,6,1
	Topic: iteblog	Partition: 6	Leader: 7	Replicas: 7,1,2	Isr: 7,1,2
	Topic: iteblog	Partition: 7	Leader: 0	Replicas: 0,2,3	Isr: 0,2,3

　　手动停止部分Broker，topic1的Partition/Replica分布如下图所示。从图中可以看到，由于Broker 1/2/4都被停止，Partition 0的Leader由原来的1变为3，Partition 1的Leader由原来的2变为5，Partition 2的Leader由原来的3变为6，Partition 3的Leader由原来的4变为7。

Topic:iteblog	PartitionCount:8	ReplicationFactor:1	Configs:
	Topic: iteblog	Partition: 0	Leader: 3	Replicas: 1,3,4	Isr: 3
	Topic: iteblog	Partition: 1	Leader: 5	Replicas: 2,4,5	Isr: 5
	Topic: iteblog	Partition: 2	Leader: 6	Replicas: 3,5,6	Isr: 5,3,6
	Topic: iteblog	Partition: 3	Leader: 7	Replicas: 4,6,7	Isr: 7,6
	Topic: iteblog	Partition: 4	Leader: 5	Replicas: 5,7,0	Isr: 5,7,0
	Topic: iteblog	Partition: 5	Leader: 6	Replicas: 6,0,1	Isr: 0,6
	Topic: iteblog	Partition: 6	Leader: 7	Replicas: 7,1,2	Isr: 7
	Topic: iteblog	Partition: 7	Leader: 0	Replicas: 0,2,3	Isr: 0,3

　　再重新启动ID为1的Broker，topic1的Partition/Replica分布如下。可以看到，虽然Broker 1已经启动（Partition 0和Partition5的ISR中有1），但是1并不是任何一个Parititon的Leader，而Broker 5/6/7都是2个Partition的Leader，即Leader的分布不均衡——一个Broker最多是2个Partition的Leader，而最少是0个Partition的Leader:

Topic:iteblog	PartitionCount:8	ReplicationFactor:1	Configs:
	Topic: iteblog	Partition: 0	Leader: 3	Replicas: 1,3,4	Isr: 3,1
	Topic: iteblog	Partition: 1	Leader: 5	Replicas: 2,4,5	Isr: 5
	Topic: iteblog	Partition: 2	Leader: 6	Replicas: 3,5,6	Isr: 5,3,6
	Topic: iteblog	Partition: 3	Leader: 7	Replicas: 4,6,7	Isr: 7,6
	Topic: iteblog	Partition: 4	Leader: 5	Replicas: 5,7,0	Isr: 5,7,0
	Topic: iteblog	Partition: 5	Leader: 6	Replicas: 6,0,1	Isr: 0,6,1
	Topic: iteblog	Partition: 6	Leader: 7	Replicas: 7,1,2	Isr: 7,1
	Topic: iteblog	Partition: 7	Leader: 0	Replicas: 0,2,3	Isr: 0,3

　　运行该工具后，topic1的Partition/Replica分布如下图所示。由图可见，除了Partition 1和Partition 3由于Broker 2和Broker 4还未启动，所以其Leader不是其Preferred Repliac外，其它所有Partition的Leader都是其Preferred Replica。同时，与运行该工具前相比，Leader的分配更均匀——一个Broker最多是2个Parittion的Leader，最少是1个Partition的Leader:

Topic:iteblog	PartitionCount:8	ReplicationFactor:1	Configs:
	Topic: iteblog	Partition: 0	Leader: 1	Replicas: 1,3,4	Isr: 3,1
	Topic: iteblog	Partition: 1	Leader: 5	Replicas: 2,4,5	Isr: 5
	Topic: iteblog	Partition: 2	Leader: 3	Replicas: 3,5,6	Isr: 5,3,6
	Topic: iteblog	Partition: 3	Leader: 7	Replicas: 4,6,7	Isr: 7,6
	Topic: iteblog	Partition: 4	Leader: 5	Replicas: 5,7,0	Isr: 5,7,0
	Topic: iteblog	Partition: 5	Leader: 6	Replicas: 6,0,1	Isr: 0,6,1
	Topic: iteblog	Partition: 6	Leader: 7	Replicas: 7,1,2	Isr: 7,1
	Topic: iteblog	Partition: 7	Leader: 0	Replicas: 0,2,3	Isr: 0,3

启动Broker 2和Broker 4，Leader分布与上一步相比并未变化，如下图所示。:

Topic:iteblog	PartitionCount:8	ReplicationFactor:1	Configs:
	Topic: iteblog	Partition: 0	Leader: 1	Replicas: 1,3,4	Isr: 3,1,4
	Topic: iteblog	Partition: 1	Leader: 5	Replicas: 2,4,5	Isr: 5,2,4
	Topic: iteblog	Partition: 2	Leader: 3	Replicas: 3,5,6	Isr: 5,3,6
	Topic: iteblog	Partition: 3	Leader: 7	Replicas: 4,6,7	Isr: 7,6,4
	Topic: iteblog	Partition: 4	Leader: 5	Replicas: 5,7,0	Isr: 5,7,0
	Topic: iteblog	Partition: 5	Leader: 6	Replicas: 6,0,1	Isr: 0,6,1
	Topic: iteblog	Partition: 6	Leader: 7	Replicas: 7,1,2	Isr: 7,1,2
	Topic: iteblog	Partition: 7	Leader: 0	Replicas: 0,2,3	Isr: 0,3,2

　　再次运行该工具，所有Partition的Leader都由其Preferred Replica承担，Leader分布更均匀——每个Broker承担1个Partition的Leader角色。

　　除了手动运行该工具使Leader分配均匀外，Kafka还提供了自动平衡Leader分配的功能，该功能可通过将auto.leader.rebalance.enable设置为true开启，它将周期性检查Leader分配是否平衡，若不平衡度超过一定阈值则自动由Controller尝试将各Partition的Leader设置为其Preferred Replica。检查周期由leader.imbalance.check.interval.seconds指定，不平衡度阈值由leader.imbalance.per.broker.percentage指定。

Kafka Reassign Partitions Tool

用途

　　该工具的设计目标与Preferred Replica Leader Election Tool有些类似，都旨在促进Kafka集群的负载均衡。不同的是，Preferred Replica Leader Election只能在Partition的AR范围内调整其Leader，使Leader分布均匀，而该工具还可以调整Partition的AR。

　　Follower需要从Leader Fetch数据以保持与Leader同步，所以仅仅保持Leader分布的平衡对整个集群的负载均衡来说是不够的。另外，生产环境下，随着负载的增大，可能需要给Kafka集群扩容。向Kafka集群中增加Broker非常简单方便，但是对于已有的Topic，并不会自动将其Partition迁移到新加入的Broker上，此时可用该工具达到此目的。某些场景下，实际负载可能远小于最初预期负载，此时可用该工具将分布在整个集群上的Partition重装分配到某些机器上，然后可以停止不需要的Broker从而实现节约资源的目的。

　　需要说明的是，该工具不仅可以调整Partition的AR位置，还可调整其AR数量，即改变该Topic的replication factor。

原理

　　该工具只负责将所需信息存入ZooKeeper中相应节点，然后退出，不负责相关的具体操作，所有调整都由Controller完成。
　　1. 在ZooKeeper上创建/admin/reassign_partitions节点，并存入目标Partition列表及其对应的目标AR列表。
　　2. Controller注册在/admin/reassign_partitions上的Watch被fire，Controller获取该列表。
　　3. 对列表中的所有Partition，Controller会做如下操作：

　　（1）、启动RAR - AR中的Replica，即新分配的Replica。（RAR = Reassigned Replicas， AR = Assigned Replicas）
　　（2）、等待新的Replica与Leader同步
　　（3）、如果Leader不在RAR中，从RAR中选出新的Leader
　　（4）、停止并删除AR - RAR中的Replica，即不再需要的Replica
　　（5）、删除/admin/reassign_partitions节点

用法

　　该工具有三种使用模式

　　（1）、generate模式，给定需要重新分配的Topic，自动生成reassign plan（并不执行）
　　（2）、execute模式，根据指定的reassign plan重新分配Partition
　　（3）、verify模式，验证重新分配Partition是否成功

　　下面这个例子将使用该工具将Topic的所有Partition重新分配到Broker 2,3 上，步骤如下：

　　1.　使用generate模式，生成reassign plan 
指定需要重新分配的Topic （{"topics":[{"topic":"iteblog"}],"version":1}），并存入/tmp/topics-to-move.json文件中，然后执行如下命令

1 $KAFKA_HOME/bin/kafka-reassign-partitions.sh --zookeeper www.iteblog.com:2181
2 --topics-to-move-json-file/tmp/topics-to-move.json
3 --broker-list "2,3" --generate

结果如下图所示

 
Current partition replica assignment

{"version":1,"partitions":[{"topic":"iteblog","partition":2,"replicas":[3]},{"topic":"iteblog","partition":6,"replicas":[1]},{"topic":"iteblog","partition":7,"replicas":[2]},{"topic":"iteblog","partition":0,"replicas":[1]},{"topic":"iteblog","partition":8,"replicas":[3]},{"topic":"iteblog","partition":5,"replicas":[3]},{"topic":"iteblog","partition":4,"replicas":[2]},{"topic":"iteblog","partition":3,"replicas":[1]},{"topic":"iteblog","partition":1,"replicas":[2]}]}
Proposed partition reassignment configuration

{"version":1,"partitions":[{"topic":"iteblog","partition":6,"replicas":[3]},{"topic":"iteblog","partition":2,"replicas":[3]},{"topic":"iteblog","partition":7,"replicas":[2]},{"topic":"iteblog","partition":0,"replicas":[3]},{"topic":"iteblog","partition":8,"replicas":[3]},{"topic":"iteblog","partition":5,"replicas":[2]},{"topic":"iteblog","partition":4,"replicas":[3]},{"topic":"iteblog","partition":1,"replicas":[2]},{"topic":"iteblog","partition":3,"replicas":[2]}]}

　　2.　使用execute模式，执行reassign plan 
将上一步生成的reassignment plan存入/tmp/reassign-plan.json文件中，并执行

1 $KAFKA_HOME/bin/kafka-reassign-partitions.sh --zookeeper www.iteblog.com:2181
2 --reassignment-json-file /tmp/reassign-plan.json --execute
Current partition replica assignment

{"version":1,"partitions":[{"topic":"iteblog","partition":2,"replicas":[3]},{"topic":"iteblog","partition":6,"replicas":[1]},{"topic":"iteblog","partition":7,"replicas":[2]},{"topic":"iteblog","partition":0,"replicas":[1]},{"topic":"iteblog","partition":8,"replicas":[3]},{"topic":"iteblog","partition":5,"replicas":[3]},{"topic":"iteblog","partition":4,"replicas":[2]},{"topic":"iteblog","partition":3,"replicas":[1]},{"topic":"iteblog","partition":1,"replicas":[2]}]}

Save this to use as the --reassignment-json-file option during rollback
Successfully started reassignment of partitions {"version":1,"partitions":[{"topic":"iteblog","partition":2,"replicas":[3]},{"topic":"iteblog","partition":6,"replicas":[3]},{"topic":"iteblog","partition":7,"replicas":[2]},{"topic":"iteblog","partition":0,"replicas":[3]},{"topic":"iteblog","partition":8,"replicas":[3]},{"topic":"iteblog","partition":4,"replicas":[3]},{"topic":"iteblog","partition":5,"replicas":[2]},{"topic":"iteblog","partition":3,"replicas":[2]},{"topic":"iteblog","partition":1,"replicas":[2]}]}

此时，ZooKeeper上/admin/reassign_partitions节点被创建，且其值与/tmp/reassign-plan.json文件的内容一致。

[zk: www.iteblog.com:2181(CONNECTED) 12] get /admin/reassign_partitions
{"version":1,"partitions":[{"topic":"iteblog","partition":2,"replicas":[3]},{"topic":"iteblog","partition":6,"replicas":[3]},{"topic":"iteblog","partition":7,"replicas":[2]},{"topic":"iteblog","partition":0,"replicas":[3]},{"topic":"iteblog","partition":8,"replicas":[3]},{"topic":"iteblog","partition":4,"replicas":[3]},{"topic":"iteblog","partition":5,"replicas":[2]},{"topic":"iteblog","partition":3,"replicas":[2]},{"topic":"iteblog","partition":1,"replicas":[2]}]}

　　3.　使用verify模式，验证reassign是否完成 
执行verify命令

1 $KAFKA_HOME/bin/kafka-reassign-partitions.sh --zookeeper www.iteblog.com:2181
2 --reassignment-json-file /tmp/reassign-plan.json --verify

结果如下所示，从图中可看出iteblog的所有Partititon都根据reassign plan重新分配成功:

Status of partition reassignment:
Reassignment of partition [iteblog,4] completed successfully
Reassignment of partition [iteblog,0] completed successfully
Reassignment of partition [iteblog,2] completed successfully
Reassignment of partition [iteblog,6] completed successfully
Reassignment of partition [iteblog,7] completed successfully
Reassignment of partition [iteblog,5] completed successfully
Reassignment of partition [iteblog,3] completed successfully
Reassignment of partition [iteblog,8] completed successfully
Reassignment of partition [iteblog,1] completed successfully

接下来用Topic Tool再次验证。

1 bin/kafka-topics.sh --zookeeper www.iteblog.com:2181 --describe --topic iteblog

结果如下图所示，从图中可看出iteblog 的所有Partition都被重新分配到Broker 2/3，且每个Partition的AR与reassign plan一致。

Topic:iteblog	PartitionCount:9	ReplicationFactor:1	Configs:
	Topic: iteblog	Partition: 0	Leader: 3	Replicas: 3	Isr: 3
	Topic: iteblog	Partition: 1	Leader: 2	Replicas: 2	Isr: 2
	Topic: iteblog	Partition: 2	Leader: 3	Replicas: 3	Isr: 3
	Topic: iteblog	Partition: 3	Leader: 2	Replicas: 2	Isr: 2
	Topic: iteblog	Partition: 4	Leader: 3	Replicas: 3	Isr: 3
	Topic: iteblog	Partition: 5	Leader: 2	Replicas: 2	Isr: 2
	Topic: iteblog	Partition: 6	Leader: 3	Replicas: 3	Isr: 3
	Topic: iteblog	Partition: 7	Leader: 2	Replicas: 2	Isr: 2
	Topic: iteblog	Partition: 8	Leader: 3	Replicas: 3	Isr: 3
　　这里附出执行上面命令之前iteblog的分布情况：

1 bin/kafka-topics.sh --zookeeper www.iteblog.com:2181 --describe --topic iteblog
Topic:iteblog	PartitionCount:9	ReplicationFactor:1	Configs:
	Topic: iteblog	Partition: 0	Leader: 1	Replicas: 1	Isr: 1
	Topic: iteblog	Partition: 1	Leader: 2	Replicas: 2	Isr: 2
	Topic: iteblog	Partition: 2	Leader: 3	Replicas: 3	Isr: 3
	Topic: iteblog	Partition: 3	Leader: 1	Replicas: 1	Isr: 1
	Topic: iteblog	Partition: 4	Leader: 2	Replicas: 2	Isr: 2
	Topic: iteblog	Partition: 5	Leader: 3	Replicas: 3	Isr: 3
	Topic: iteblog	Partition: 6	Leader: 1	Replicas: 1	Isr: 1
	Topic: iteblog	Partition: 7	Leader: 2	Replicas: 2	Isr: 2
	Topic: iteblog	Partition: 8	Leader: 3	Replicas: 3	Isr: 3

　　需要说明的是，在使用execute之前，并不一定要使用generate模式自动生成reassign plan，使用generate模式只是为了方便。事实上，某些场景下，generate模式生成的reassign plan并不一定能满足需求，此时用户可以自己设置reassign plan。

State Change Log Merge Tool

用途

　　该工具旨在从整个集群的Broker上收集状态改变日志，并生成一个集中的格式化的日志以帮助诊断状态改变相关的故障。每个Broker都会将其收到的状态改变相关的的指令存于名为state-change.log的日志文件中。某些情况下，Partition的Leader election可能会出现问题，此时我们需要对整个集群的状态改变有个全局的了解从而诊断故障并解决问题。该工具将集群中相关的state-change.log日志按时间顺序合并，同时支持用户输入时间范围和目标Topic及Partition作为过滤条件，最终将格式化的结果输出。

用法

1 bin/kafka-run-class.sh kafka.tools.StateChangeLogMerger
2 --logs /opt/kafka_2.11-0.8.2.1/logs/state-change.log
3 --topic iteblog --partitions 0,1,2,3,4,5,6,7
笔尖的痕
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Kafka技术内幕：图文详解Kafka源码设计与实现 PD
03-16
Kafka技术内幕：图文详解Kafka源码设计与实现 PDF 下载 Kafka技术内幕：图文详解Kafka源码设计与实现 PDF 下载
kafka shell脚本用法详解
I_No_dream的博客
03-31 1077
注：使用kafka脚本时，想要查看help直接执行脚本即可，参数说明都挺详细的，以及像topic能配置的参数也全都有 1. kafka-shell bin目录下，windows的.bat和.sh使用方法相同 脚本名称 用途描述 connect-distributed.sh 连接kafka集群模式 connect-standalone.sh 连接kafka单机模式 kafka-acls.sh todo kafka-broker-api-versions.sh todo kafk
Kafka命令介绍和使用以及案例
码农崛起
08-16 1423
TopicCommand.createTopic() 方法负责创建 Topic，其核心逻辑是确定新建 Topic 中有多少个分区及每个分区中的副本如何分配，既支持使用 replica-assignment 参数手动分配，也支持使用 partitions 参数和 replication-factor 参数指定分区个数和副本个数进行自动分配。执行上述命令后，就会在控制台等待键入消息体，直接输入消息值(value)即可，每行（以换行符分隔）表示一条消息，如下所示。生产消息有存入到分区中，有三种方式。.......
kafka知识点全方位讲解
weixin_42435657的博客
10-20 2303
Apache Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目。 Kafka最初是由LinkedIn开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。 Kafka是一个分布式消息队列：生产者、消费者的功能。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。 Kafka对消息保存时根据Topic进行归类，发送消息者称为Produ
深入剖析Kafka设计原理：如何构建高效的消息系统
最新发布
12-25
本文详细解析了Kafka的设计原理，重点介绍了Kafka作为一种高效的分布式消息系统的核心组件和机制。首先，文档解释了Kafka的总控制器（Controller）的作用，它负责管理集群中的分区和副本状态，并在必要时进行Leader...
Kafka设计解析（五）-KafkaConsumer设计解析
02-25
以及未来版本中对HighLevelConsumer的重新设计——使用ConsumerCoordinator解决SplitBrain和Herd等问题。很多时候，客户程序只是希望从Kafka读取数据，不太关心消息offset的处理。同时也希望提供一些语义，例如同一...
Kafka设计解析
12-10
针对kafka设计原理作了深入的解析，通过该文档可以了解kafka的设计理念和原理。
kafka 脚本发送_9. kafka shell脚本用法详解
weixin_39815345的博客
12-22 440
9. kafka shell脚本用法详解发布时间：2018-07-14 21:18,浏览次数：1936, 标签：kafkashellkafka安装目录下的bin目录包含了很多运维可操作的shell脚本，列举如下：脚本名称 用途描述connect-distributed.sh 连接kafka集群模式connect-standalone.sh 连接kafka单机模式kafka-acls.sh todo...
Kafka详解（五）Kafka副本机制
傅红雪的专栏
01-15 1083
所谓的副本机制（Replication），也可以称之为备份机制，通常是指分布式系统在多台网络互联的机器上保存有相同的数据拷贝。它的作用主要有以下几点： 提供数据冗余。即使系统部分组件失效，系统依然能够继续运转，因而增加了整体可用性以及数据持久性。 提供高伸缩性。支持横向扩展，能够通过增加机器的方式来提升读性能，进而提高读操作吞吐量。 改善数据局部性。允许将数据放入与用户地理位置相近的地方，从...
k8s 入门 伸缩应用程序
一片冰心
06-01 386
伸缩应用程序 目标 使用 kubectl 伸缩应用程序。 Scaling（伸缩）应用程序 在之前的文章中，我们创建了一个 Deployment (opens new window，然后通过 服务 (opens new window提供访问 Pod 的方式。我们发布的 Deployment 只创建了一个 Pod 来运行我们的应用程序。当流量增加时，我们需要对应用程序进行伸缩操作以满足系统性能需求。 伸缩 的实现可以通过更改 nginx-deployment.yaml 文件中部署的 replicas（副本数
kafka 常用运维命令介绍（二）
u013332124的专栏
12-09 2032
文章目录一、producer 相关命令1. kafka-console-producer 生产消息2. 使用 kafka-producer-perf-test 进行producer的基准测试3. 使用 kafka-verifiable-producer 批量推送消息4. 使用kafka-replay-log-producer进行topic之间的消息复制二、consumer相关命令1. kafka...
Kafka 副本管理模块（三）：ReplicaManager 类介绍
lianggx3的博客
10-02 308
ReplicaManager 负责管理和操作集群中 Broker 的副本，它定义如下： class ReplicaManager(val config: KafkaConfig, // 配置管理类 metrics: Metrics, // 监控指标类 time: Time, // 定时器类 val zkClient: KafkaZkClient, // ZooKeeper客户端
kafka源码愫读（5）、ReplicaManager模块源码分析
yuanwei1144的博客
02-03 422
1、ReplicaManager模块简介 replicaManager主要用来管理topic在本broker上的副本信息。并且读写日志的请求都是通过replicaManager进行处理的。 每个replicaManager实例都会持有一个Pool[TopicPartition, Partition]类型的allPartitions变量。Pool其实就是一个Map的封装。通过key(TopicPar...
kafka详解
qq_45927587的博客
12-21 6003
Kafka:分布式消息中间件 Kafka 来做消息通信。 分布式消息系统 开发人员必备的技能
9. kafka shell脚本用法详解
热门推荐
阿飞Javaer的专栏
07-14 1万+
kafka安装目录下的bin目录包含了很多运维可操作的shell脚本，列举如下： 脚本名称 用途描述 connect-distributed.sh 连接kafka集群模式 connect-standalone.sh 连接kafka单机模式 kafka-acls.sh todo kafka-broker-api-versions.sh ...
kafka配置参数
weixin_42496486的博客
05-21 993
kafka常见的参数
kafka 监控工具
dymkkj的专栏
07-13 1726
一 kafka某个offset的监控工具 (1).开源社区有相应的组件进行监控 a.下载 kafka offset监控 (地址链接)https://pan.baidu.com/s/1sj0YERV  (如果失效,可以上社区搜索) b. 解压后发现KafkaOffsetMonitor-assembly-0.2.1.jar,即为监控组件 c.编写脚本(可定时启动) KafkaOffsetMonitor...
kafka: topic: authorization: add:
05-09
这看起来像是Kafka中的命令，具体解释如下： - `kafka`: 是一个分布式流处理平台，用于处理实时数据流。 - `topic`: 是Kafka中的概念，表示一组相关消息的集合。 - `authorization`: 是指授权，通常是指对访问某些资源或执行某些操作进行授权。 - `add`: 是指向Kafka中添加一个新的topic。 因此，这个命令的意思是向Kafka中添加一个新的topic，并针对该topic进行授权。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值