Kafka设计解析：Replication工具

最新推荐文章于 2022-10-20 11:27:17 发布
最新推荐文章于 2022-10-20 11:27:17 发布
阅读量813 收藏
点赞数
分类专栏： Kafka

原文链接http://www.jasongj.com/2015/06/08/KafkaColumn3

Kafka设计解析：Replication工具

博客地址：
文章标题：
本文链接：
Hadoop、Hive、Hbase、Flume等QQ交流群：138615359（已满），请加入新群：149892483
本博客的微信公共帐号为：iteblog_hadoop，欢迎大家关注。 如果你觉得本文对你有帮助，不妨分享一次，你的每次支持，都是对我最大的鼓励
 

　　 《Kafka剖析：Kafka背景及架构介绍》
　　 《Kafka设计解析：Kafka High Availability（上）》
　　 《Kafka设计解析：Kafka High Availability （下）》
　　 《Kafka设计解析：Replication工具》

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
本博客文章除特别声明，全部都是原创！
尊重原创，转载请注明： 转载自过往记忆（http://www.iteblog.com/）
本文链接地址: 《Kafka设计解析：Replication工具》（http://www.iteblog.com/archives/1384）
XiaoGuang-Xu
关注
专栏目录
【kafka】kafka duplicate brokers in replica assignment
九师兄
11-24 206
1.概述 kafka报错 duplicate brokers in replica assignment 请参考：【kafka】kafka 0.10以及1.x版本的kafka topic 分区扩容
Replication工具
weixin_33918357的博客
11-16 156
所有工具都在$KAFKA_HOME/bin目录下 kafka-topics.sh 该工具可用于创建、删除、修改、查看某个Topic，也可用于列出所有Topic。另外，该工具还可修改某个Topic的以下配置。unclean.leader.election.enabledelete.retention.mssegment.jitter.msretention...
Kafka 2.x AdminUtils -- Topic Partition Replica Assignment
10-05 352
概念 创建Topic时，需要指定partitions和replication-factor，而最重要的是尽量均匀的把每个replica分发到Brokers集群中。 kafka-topics.sh提供了两种方式： 指定replica-assignment, 即完全人为分配，指定某个replica分配到某个broker上面 由Kafka默认策略分配 默认分配原则如下： 1. Spread the replicas evenly among brokers. ...
Kafka 副本管理模块（三）：ReplicaManager 类介绍
lianggx3的博客
10-02 382
ReplicaManager 负责管理和操作集群中 Broker 的副本，它定义如下： class ReplicaManager(val config: KafkaConfig, // 配置管理类 metrics: Metrics, // 监控指标类 time: Time, // 定时器类 val zkClient: KafkaZkClient, // ZooKeeper客户端
kafka源码愫读（5）、ReplicaManager模块源码分析
yuanwei1144的博客
02-03 487
1、ReplicaManager模块简介 replicaManager主要用来管理topic在本broker上的副本信息。并且读写日志的请求都是通过replicaManager进行处理的。 每个replicaManager实例都会持有一个Pool[TopicPartition, Partition]类型的allPartitions变量。Pool其实就是一个Map的封装。通过key(TopicPar...
Kafka高可用性解析：Replication工具与管理
"Kafka设计解析（四）KafkaHighAvailability（下）" 在Kafka设计中，高可用性（High Availability, HA）是至关重要的，它确保即使在节点故障时，服务仍然能够继续运行，数据不会丢失。本篇文章是关于Kafka High ...
Kafka深度解析：从入门到实践
Kafka的灵活性和高性能使其成为实时计算和大数据领域的重要工具，它可以与其他大数据框架如Spark、Storm集成，实现复杂的数据处理任务。通过理解Kafka的核心概念、工作原理以及实际部署和使用，开发者能够更好地利用...
Kafka深度解析：分布式消息队列的实践
"Kafka是一个分布式的消息队列系统，常用于大数据实时流处理，与Storm或SparkStreaming等工具集成。其核心原理包括：多broker集群、分区与副本机制、以及Leader-Follower结构等。Kafka的特性使得它在消息处理中具有...
Kafka深度解析：分布式消息系统的强大特性
3. 可扩展性：Kafka设计为分布式系统，可以方便地增加或减少生产者、代理（Broker）和消费者，无需停机。 4. 消费状态管理：消费者端负责维护消息处理状态，这意味着即使服务器故障，消费者的消费进度不会丢失，...
Kafka深度解析：架构、机制与实战测试
"Kafka深度分析" ...总结来说，Kafka凭借其高效、灵活、可扩展的特性，已成为现代大数据和实时流处理场景中的重要工具。理解并掌握Kafka的内部机制，对于构建稳定、高性能的数据处理系统至关重要。
kafka shell脚本用法详解
I_No_dream的博客
03-31 1243
注：使用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知识点全方位讲解
weixin_42435657的博客
10-20 2966
Apache Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目。 Kafka最初是由LinkedIn开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。 Kafka是一个分布式消息队列：生产者、消费者的功能。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。 Kafka对消息保存时根据Topic进行归类，发送消息者称为Produ
Kafka详解（五）Kafka副本机制
傅红雪的专栏
01-15 1176
所谓的副本机制（Replication），也可以称之为备份机制，通常是指分布式系统在多台网络互联的机器上保存有相同的数据拷贝。它的作用主要有以下几点： 提供数据冗余。即使系统部分组件失效，系统依然能够继续运转，因而增加了整体可用性以及数据持久性。 提供高伸缩性。支持横向扩展，能够通过增加机器的方式来提升读性能，进而提高读操作吞吐量。 改善数据局部性。允许将数据放入与用户地理位置相近的地方，从...
Kafka设计解析（三）：Kafka High Availability （下）
beyondlpf的专栏
07-06 259
http://www.infoq.com/cn/articles/kafka-analysis-part-3?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk   Kafka是由LinkedIn开发的一个分布式的消息系统，使用Scala编写，它以可...
Kafka生产者分区写入规则和副本机制
大数据跟我学i
03-31 1652
文章目录生产者分区写入规则概述分类副本机制概述producer的ACKS参数参数分类 生产者分区写入规则 概述 生产者写入消息到topic，Kafka将依据不同的规则将数据分配到不同的分区中，如果指定了分区数据就会写到指定分区，如果没有指定分区，会按照下列若干规则进行指定分区： 分类 Hash分区(指定Key默认开启) 优点：相同的key会进去同一分区 缺点：由于相同key的Hash取余结果是相同的，会导致数据倾斜问题 轮询分区(没有指定Key时开启) 默认的策略，也是使用最多的策略，可以最大限度
kafka topic增加replica报错解决
黄刚的技术博客
10-27 7587
刚开始测试环境中给一个业务方建的topic没有增加replica，导致前天虚拟机down掉，业务方反馈无法写入的问题。于是决定将所有replica为1的topic改为2，于是照着官方文档上的说明试试，但由于编辑json文件出错了，却手贱地执行了 －－execute，后面即使改对，也无法成功。总是报错： bin/kafka-reassign-partitions.sh --zookeeper
k8s 控制器-Statefulset & ConfigMap
热门推荐
高飞的博客
11-10 26万+
k8s StatefulSet ConfigMap
如何在Kafka中修改Topic的preferred replica
李志涛的专栏
05-21 8605
操作背景假如topic test.example中partition 0的replicas为[0,4]，则0为preferred replica，应该成为leader。 这时我们期望4为preferred replica，并变成leader。执行步骤如下：1.查看当前的topic详细信息： lizhitao@users-MacBook-Pro-2:~$ ./bin/kafka-topics.sh
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值