Apache Kafka-初体验Kafka(03)-Centos7下搭建kafka集群

简介: Apache Kafka-初体验Kafka(03)-Centos7下搭建kafka集群


概述

对于kafka来说,一个单独的broker意味着kafka集群中只有一个节点。要想增加kafka集群中的节点数量,只需要多启动几个broker实例即可。

单个节点的安装: Kafka-初体验Kafka(02)-Centos7下搭建单节点kafka_2.11‐1.1.0

这里我们来搭建个3个节点的kafka集群来体验下吧


部署信息

192.168.18.130 —> kafka 、 zookeeper(单节点的zk)

192.168.18.131 —> kafka

192.168.18.132 —> kafka

单节点的 zk , 部署上 130上,事实上生产环境的话,zk也是要搭建集群的,这里演示用的话,用单个节点的zk先。

3个节点的kafka注册到 单节点的zk上。


配置信息

kafka的配置文件主要是配置文件 server.properties

130

[root@artisan config]# grep -Ev '^$|^[#;]' server.properties 
broker.id=0
listeners=PLAINTEXT://192.168.18.130:9092
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/tmp/kafka-logs
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=192.168.18.130:2181
zookeeper.connection.timeout.ms=6000
group.initial.rebalance.delay.ms=0
[root@artisan config]# 


131

[root@artisan config]#  grep -Ev '^$|^[#;]' server.properties
broker.id=1
listeners=PLAINTEXT://192.168.18.131:9092
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/tmp/kafka-logs
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=192.168.18.130:2181
zookeeper.connection.timeout.ms=6000
group.initial.rebalance.de


132

[root@artisan config]#  grep -Ev '^$|^[#;]' server.properties
broker.id=2
listeners=PLAINTEXT://192.168.18.132:9092
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/tmp/kafka-logs
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=192.168.18.130:2181
zookeeper.connection.timeout.ms=6000
group.initial.rebalance.delay.ms=0
[root@artisan config]# 

还有一篇博主写的 zk也是高可用的,可以参考下,写的很不错 ZooKeeper+Kafka 高可用集群搭建


验证

启动zookeeper 和 3个 kafka 后,我们创建一个新的topic,副本数设置为3,分区数设置为2

[root@artisan bin]# ./kafka-topics.sh --create --zookeeper 192.168.18.130:2181 --replication-factor 3 --partitions 2 --topic artisan-replicated-topic
Created topic "artisan-replicated-topic".
[root@artisan bin]# 

查看topic的情况

[root@artisan bin]# ./kafka-topics.sh --describe --zookeeper 192.168.18.130:2181 --topic artisan-replicated-topic
Topic:artisan-replicated-topic  PartitionCount:2  ReplicationFactor:3 Configs:
  Topic: artisan-replicated-topic Partition: 0  Leader: 1 Replicas: 1,2,0 Isr: 1,2,0
  Topic: artisan-replicated-topic Partition: 1  Leader: 2 Replicas: 2,0,1 Isr: 2,0,1
[root@artisan bin]# 

我们来解释下上面的输出内容

第一行是所有分区的概要信息,之后的每一行表示每一个partition的信息。

所有分区的概要信息:

Topic:artisan-replicated-topic  PartitionCount:2  ReplicationFactor:3 Configs

每一个partition的信息:

Topic: artisan-replicated-topic Partition: 0  Leader: 1 Replicas: 1,2,0 Isr: 1,2,0
Topic: artisan-replicated-topic Partition: 1  Leader: 2 Replicas: 2,0,1 Isr: 2,0,1
  • leader节点负责给定partition的所有读写请求。
  • replicas 表示某个partition在哪几个broker上存在备份。不管这个几点是不是”leader“,甚至这个节点挂了,也会列出
  • isr 是replicas的一个子集,它只列出当前还存活着的,并且已同步备份了该partition的节点。

我们可以运行相同的命令查看之前创建的名称为”artisan“的topic

[root@artisan bin]# ./kafka-topics.sh --describe --zookeeper 192.168.18.130:2181 --topic artisan
Topic:artisan PartitionCount:1  ReplicationFactor:1 Configs:
  Topic: artisan  Partition: 0  Leader: 0 Replicas: 0 Isr: 0
[root@artisan bin]# 

之前设置了topic的partition数量为1,备份因子为1,因此显示就如上所示了。当然我们也可以通过如下命令增加topic的分区数量(目前kafka不支持减少分区):

[root@artisan bin]# ./kafka-topics.sh --alter --partitions 3 --zookeeper 192.168.18.130:2181 --topic artisan
WARNING: If partitions are increased for a topic that has a key, the partition logic or ordering of the messages will be affected
Adding partitions succeeded!

重新查看

[root@artisan bin]# ./kafka-topics.sh --describe --zookeeper 192.168.18.130:2181 --topic artisan
Topic:artisan PartitionCount:3  ReplicationFactor:1 Configs:
  Topic: artisan  Partition: 0  Leader: 0 Replicas: 0 Isr: 0
  Topic: artisan  Partition: 1  Leader: 1 Replicas: 1 Isr: 1
  Topic: artisan  Partition: 2  Leader: 2 Replicas: 2 Isr: 2
[root@artisan bin]# 

现在我们向新建的 artisan-replicated-topic 中发送一些message,kafka集群可以加上所有kafka节点:

[root@artisan bin]# ./kafka-console-producer.sh --broker-list 192.168.18.130:9092,192.168.18.131:9092,192.168.18.132:9092 --topic  artisan-replicated-topic
>artisan message test 1
>artisan message test 2
>artisan message test 3
>

现在131broker 开始消费:

[root@artisan bin]# ./kafka-console-consumer.sh --bootstrap-server 192.168.18.131:9092 --from-beginning --topic artisan-replicated-topic
artisan message test 1
artisan message test 3
artisan message test 2

现在我们来测试我们 容错性 ,因为broker1目前是artisan-replicated-topic的分区0的 leader,所以我们要将其kill , kill 掉 131 节点的 kafka

再执行

[root@artisan bin]# ./kafka-topics.sh --describe --zookeeper 192.168.18.130:2181 --topic artisan-replicated-topic
Topic:artisan-replicated-topic  PartitionCount:2  ReplicationFactor:3 Configs:
  Topic: artisan-replicated-topic Partition: 0  Leader: 2 Replicas: 1,2,0 Isr: 0,2
  Topic: artisan-replicated-topic Partition: 1  Leader: 2 Replicas: 2,0,1 Isr: 2,0
[root@artisan bin]# 

我们可以看到,分区0的leader节点已经变成了broker 2。要注意的是,在Isr中,已经没有了1号节点。leader的选举也是从ISR(in-sync replica)中进行的。

131 重新起来以后,还是可以消费消息

[root@artisan bin]# ./kafka-server-start.sh -daemon ../config/server.properties 
[root@artisan bin]# jps
24436 Kafka
24455 Jps
[root@artisan bin]# ./kafka-console-consumer.sh --bootstrap-server 192.168.18.131:9092 --from-beginning --topic artisan-replicated-topic
artisan message test 1
artisan message test 3
artisan message test 2

再看下

[root@artisan bin]# ./kafka-topics.sh --describe --zookeeper 192.168.18.130:2181 --topic artisan-replicated-topic
Topic:artisan-replicated-topic  PartitionCount:2  ReplicationFactor:3 Configs:
  Topic: artisan-replicated-topic Partition: 0  Leader: 1 Replicas: 1,2,0 Isr: 0,2,1
  Topic: artisan-replicated-topic Partition: 1  Leader: 2 Replicas: 2,0,1 Isr: 2,0,1
[root@artisan bin]# 
[root@artisan bin]# 


相关文章
|
9月前
|
消息中间件 监控 Java
Apache Kafka 分布式流处理平台技术详解与实践指南
本文档全面介绍 Apache Kafka 分布式流处理平台的核心概念、架构设计和实践应用。作为高吞吐量、低延迟的分布式消息系统,Kafka 已成为现代数据管道和流处理应用的事实标准。本文将深入探讨其生产者-消费者模型、主题分区机制、副本复制、流处理API等核心机制,帮助开发者构建可靠、可扩展的实时数据流处理系统。
809 4
|
分布式计算 Hadoop Java
CentOS中构建高可用Hadoop 3集群
这个过程像是在一个未知的森林中探索。但当你抵达终点,看到那个熟悉的Hadoop管理界面时,所有的艰辛都会化为乌有。仔细观察,尽全力,这就是构建高可用Hadoop 3集群的挑战之旅。
452 21
|
11月前
|
消息中间件 存储 监控
Apache Kafka 3.0与KRaft模式的革新解读
在该架构中,Kafka集群依旧包含多个broker节点,但已不再依赖ZooKeeper集群。被选中的Kafka集群Controller将从KRaft Quorum中加载其状态,并在必要时通知其他Broker节点关于元数据的变更。这种设计支持更多分区与快速Controller切换,并有效避免了因数据不一致导致的问题。
|
Java Linux
CentOS环境搭建Elasticsearch集群
至此,您已成功在CentOS环境下搭建了Elasticsearch集群。通过以上介绍和步骤,相信您对部署Elasticsearch集群有了充分的了解。最后祝您在使用Elasticsearch集群的过程中顺利开展工作!
651 22
|
消息中间件 Java Kafka
什么是Apache Kafka?如何将其与Spring Boot集成?
什么是Apache Kafka?如何将其与Spring Boot集成?
864 5
|
消息中间件 存储 缓存
kafka 的数据是放在磁盘上还是内存上,为什么速度会快?
Kafka的数据存储机制通过将数据同时写入磁盘和内存,确保高吞吐量与持久性。其日志文件按主题和分区组织,使用预写日志(WAL)保证数据持久性,并借助操作系统的页缓存加速读取。Kafka采用顺序I/O、零拷贝技术和批量处理优化性能,支持分区分段以实现并行处理。示例代码展示了如何使用KafkaProducer发送消息。
|
消息中间件 存储 运维
为什么说Kafka还不是完美的实时数据通道
【10月更文挑战第19天】Kafka 虽然作为数据通道被广泛应用,但在实时性、数据一致性、性能及管理方面存在局限。数据延迟受消息堆积和分区再平衡影响;数据一致性难以达到恰好一次;性能瓶颈在于网络和磁盘I/O;管理复杂性涉及集群配置与版本升级。
664 1
|
消息中间件 Java Kafka
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
513 1
|
消息中间件 Java Kafka
Kafka不重复消费的终极秘籍!解锁幂等性、偏移量、去重神器,让你的数据流稳如老狗,告别数据混乱时代!
【8月更文挑战第24天】Apache Kafka作为一款领先的分布式流处理平台,凭借其卓越的高吞吐量与低延迟特性,在大数据处理领域中占据重要地位。然而,在利用Kafka进行数据处理时,如何有效避免重复消费成为众多开发者关注的焦点。本文深入探讨了Kafka中可能出现重复消费的原因,并提出了四种实用的解决方案:利用消息偏移量手动控制消费进度;启用幂等性生产者确保消息不被重复发送;在消费者端实施去重机制;以及借助Kafka的事务支持实现精确的一次性处理。通过这些方法,开发者可根据不同的应用场景灵活选择最适合的策略,从而保障数据处理的准确性和一致性。
1664 9
|
消息中间件 监控 Kafka
实时计算 Flink版产品使用问题之处理Kafka数据顺序时,怎么确保事件的顺序性
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。