KAFKA集群搭建

简介:

环境:

  • CentOS 6.5

  • KAFKA版本: kafka_2.11-0.8.2.1

  • ZOOKEEPER版本: zookeeper-3.4.6

  • JDK: 1.8.0_151

  • SERVER: 172.16.2.27、172.16.2.28、172.16.2.29




一、准备:

1、安装JDK1.8

2、下载kafka和zookeeper安装包(二进制包)

下载地址:

kafka:http://kafka.apache.org/downloads 下载合适版本

zookeeper: http://zookeeper.apache.org/releases.html  下载合适版本


二、安装zookeeper集群

1
2
3
4
5
6
7
8
9
10
11
12
##将安装文件解压缩到/usr/local目录
tar  zxf zookeeper-3.4.6. tar .gz -C  /usr/local
 
##创建软连接
ln  -s  /usr/local/zookeeper-3 .4.6   /usr/local/zookeeper
 
##从模板复制配置文件
cd  /usr/local/zookeeper/conf
cp  zoo_sample.cfg  zoo.cfg
 
##创建data目录
mkdir  -p  /data/zookeeper/ {zkdata,zkdatalog}


修改配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
cat  zoo.cfg |  egrep  - v  "^#|^$"
tickTime=2000  
initLimit=10
syncLimit=5
dataDir= /data/zookeeper/zkdata
dataLogDir= /data/zookeeper/zkdatalog
clientPort=2181
server.1=172.16.2.27:2888:3888
server.2=172.16.2.28:2888:3888
server.3=172.16.2.29:2888:3888
autopurge.snapRetainCount=30
autopurge.purgeInterval=24
###server.1 这个1是服务器的标识也可以是其他的数字, 表示这个是第几号服务器,用来标识服务器
这个标识要写到快照目录下面myid文件里
#172.16.2.27为集群里的IP地址,第一个端口是master和slave之间的通信端口,默认是2888,
第二个端口是leader选举的端口,集群刚启动的时候选举或者leader挂掉之后进行新的选举的端口默认是3888

三台服务器上的配置是一样的


配置文件解释:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#tickTime:
这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个 tickTime 时间就会发送一个心跳。
 
#initLimit:
这个配置项是用来配置 Zookeeper 接受客户端(这里所说的客户端不是用户连接 Zookeeper 服务器的客户端,而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器)初始化连接时最长能忍受多少个心跳时间间隔数。
当已经超过 5个心跳的时间(也就是 tickTime)长度后 Zookeeper 服务器还没有收到客户端的返回信息,那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
#syncLimit:
这个配置项标识 Leader 与Follower 之间发送消息,请求和应答时间长度,最长不能超过多少个 tickTime 的时间长度,总的时间长度就是5*2000=10秒
#dataDir:
快照日志的存储路径
#dataLogDir:
事物日志的存储路径,如果不配置这个那么事物日志会默认存储到dataDir制定的目录,这样会严重影响zk的性能,当zk吞吐量较大的时候,产生的事物日志、快照日志太多
#clientPort:
这个端口就是客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客户端的访问请求。修改他的端口改大点


创建myid文件

1
2
3
4
5
6
#server1
echo  "1"  /data/zookeeper/zkdata/myid
#server2
echo  "2"  /data/zookeeper/zkdata/myid
#server3
echo  "3"  > /data/zookeeper/zkdata/myid


重要说明

1、myid文件和server.myid  在快照目录下存放的标识本台服务器的文件,他是整个zk集群用来发现彼此的一个重要标识。

2、zoo.cfg 文件是zookeeper配置文件 在conf目录里。

3、log4j.properties文件是zk的日志输出文件 在conf目录里用java写的程序基本上有个共同点日志都用log4j,来进行管理。

4、zkEnv.sh和zkServer.sh文件

zkServer.sh 主的管理程序文件

zkEnv.sh 是主要配置,zookeeper集群启动时配置环境变量的文件

5、还有一个需要注意

ZooKeeper server will not remove old snapshots and log files when using the default configuration (see autopurge below), this is the responsibility of the operator

zookeeper不会主动的清除旧的快照和日志文件,这个是操作者的责任。

清理ZooKeeper日志的方法请参考:https://www.cnblogs.com/luotianshuai/p/5206662.html


启动ZooKeeper服务

1
2
3
4
5
6
7
cd  /usr/local/zookeeper/bin
. /zkServer .sh start
##查看状态
. /zkServer .sh status
JMX enabled by default
Using config:  /usr/local/zookeeper/bin/ .. /conf/zoo .cfg   ##zookeeper使用的配置文件
Mode: follower   ##zookeeper的角色



三、安装KAFKA集群

1
2
3
4
tar  zxf kafka_2.11-0.8.2.1.tgz -C  /usr/local
ln  -s  /usr/local/kafka_2 .11-0.8.2.1   /usr/local/kafka
cd  /usr/local/kafka
cp  server.properties server.properties.bak


修改配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
broker. id =0   #当前机器在集群中的唯一标识,和zookeeper的myid性质一样
port=19092  #当前kafka对外提供服务的端口默认是9092
host.name=172.16.2.27  #这个参数默认是关闭的,在0.8.1有个bug,DNS解析问题,失败率的问题。
num.network.threads=3  #这个是borker进行网络处理的线程数
num.io.threads=8  #这个是borker进行I/O处理的线程数
log. dirs =log. dirs = /data/kafka/kafka-logs  #消息存放的目录,这个目录可以配置为“,”逗号分割的表达式,上面的num.io.threads要大于这个目录的个数这个目录,如果配置多个目录,新创建的topic他把消息持久化的地方是,当前以逗号分割的目录中,那个分区数最少就放那一个
socket.send.buffer.bytes=102400  #发送缓冲区buffer大小,数据不是一下子就发送的,先回存储到缓冲区了到达一定的大小后在发送,能提高性能
socket.receive.buffer.bytes=102400  #kafka接收缓冲区大小,当数据到达一定大小后在序列化到磁盘
socket.request.max.bytes=104857600  #这个参数是向kafka请求消息或者向kafka发送消息的请请求的最大数,这个值不能超过java的堆栈大小
num.partitions=1  #默认的分区数,一个topic默认1个分区数
log.retention.hours=168  #默认消息的最大持久化时间,168小时,7天
message.max.byte=5242880   #消息保存的最大值5M
default.replication.factor=2   #kafka保存消息的副本数,如果一个副本失效了,另一个还可以继续提供服务
replica.fetch.max.bytes=5242880   #取消息的最大直接数
log.segment.bytes=1073741824  #这个参数是:因为kafka的消息是以追加的形式落地到文件,当超过这个值的时候,kafka会新起一个文件
log.retention.check.interval.ms=300000  #每隔300000毫秒去检查上面配置的log失效时间(log.retention.hours=168 ),到目录查看是否有过期的消息如果有,删除
log.cleaner. enable = false  #是否启用log压缩,一般不用启用,启用的话可以提高性能
zookeeper.connect=172.16.2.27:2181,172.16.2.28:2181,172.16.2.29:2181  #设置zookeeper的连接端口


配置文件解释:

1
2
3
4
5
6
7
8
9
broker. id =0  每台服务器的broker. id 都不能相同
 
host.name=172.16.2.27
#在log.retention.hours=168 下面新增下面三项
message.max.byte=5242880
default.replication.factor=2
replica.fetch.max.bytes=5242880
#设置zookeeper的连接端口
zookeeper.connect=172.16.2.27:2181,172.16.2.28:2181,172.16.2.29:2181


启动kafka服务并测试:

1
2
3
#从后台启动Kafka集群(3台都需要启动)
cd  /usr/local/kafka/bin/  #进入到kafka的bin目录 
. /kafka-server-start .sh -daemon .. /config/server .properties


检查kafka服务是否启动

1
2
3
4
5
# jps
67137 Kafka
111089 ProdServerStart
122216 Jps
114635 QuorumPeerMain


三台服务器上配置基本一样,除了下面两条配置不同

1
2
broker. id =0
host.name=172.16.2.27










本文转自 曾哥最爱 51CTO博客,原文链接:http://blog.51cto.com/zengestudy/2049745,如需转载请自行联系原作者

目录
相关文章
|
消息中间件 存储 监控
构建高可用性Apache Kafka集群:从理论到实践
【10月更文挑战第24天】随着大数据时代的到来,数据传输与处理的需求日益增长。Apache Kafka作为一个高性能的消息队列服务,因其出色的吞吐量、可扩展性和容错能力而受到广泛欢迎。然而,在构建大规模生产环境下的Kafka集群时,保证其高可用性是至关重要的。本文将从个人实践经验出发,详细介绍如何构建一个高可用性的Kafka集群,包括集群规划、节点配置以及故障恢复机制等方面。
634 4
|
消息中间件 监控 数据可视化
大数据-79 Kafka 集群模式 集群监控方案 JavaAPI获取集群指标 可视化监控集群方案: jconsole、Kafka Eagle
大数据-79 Kafka 集群模式 集群监控方案 JavaAPI获取集群指标 可视化监控集群方案: jconsole、Kafka Eagle
624 2
|
消息中间件 运维 Java
搭建Zookeeper、Kafka集群
本文详细介绍了Zookeeper和Kafka集群的搭建过程,涵盖系统环境配置、IP设置、主机名设定、防火墙与Selinux关闭、JDK安装等基础步骤。随后深入讲解了Zookeeper集群的安装与配置,包括数据目录创建、节点信息设置、SASL认证配置及服务启动管理。接着描述了Kafka集群的安装,涉及配置文件修改、安全认证设置、生产消费认证以及服务启停操作。最后通过创建Topic、发送与查看消息等测试验证集群功能。全网可搜《小陈运维》获取更多信息。
1146 1
|
消息中间件 Java Kafka
【手把手教你Linux环境下快速搭建Kafka集群】内含脚本分发教程,实现一键部署多个Kafka节点
本文介绍了Kafka集群的搭建过程,涵盖从虚拟机安装到集群测试的详细步骤。首先规划了集群架构,包括三台Kafka Broker节点,并说明了分布式环境下的服务进程配置。接着,通过VMware导入模板机并克隆出三台虚拟机(kafka-broker1、kafka-broker2、kafka-broker3),分别设置IP地址和主机名。随后,依次安装JDK、ZooKeeper和Kafka,并配置相应的环境变量与启动脚本,确保各组件能正常运行。最后,通过编写启停脚本简化集群的操作流程,并对集群进行测试,验证其功能完整性。整个过程强调了自动化脚本的应用,提高了部署效率。
3736 1
【手把手教你Linux环境下快速搭建Kafka集群】内含脚本分发教程,实现一键部署多个Kafka节点
|
消息中间件 人工智能 安全
秒级灾备恢复:Kafka 2025 AI自愈集群下载及跨云Topic迁移终极教程
Apache Kafka 2025作为企业级实时数据中枢,实现五大革新:量子安全传输(CRYSTALS-Kyber抗量子加密算法)、联邦学习总线(支持TensorFlow Federated/Horizontal FL框架)、AI自愈集群(MTTR缩短至30秒内)、多模态数据处理(原生支持视频流、3D点云等)和跨云弹性扩展(AWS/GCP/Azure间自动迁移)。平台采用混合云基础设施矩阵与软件依赖拓扑设计,提供智能部署架构。安装流程涵盖抗量子安装包获取、量子密钥配置及联邦学习总线设置。
|
消息中间件 存储 Prometheus
Kafka集群如何配置高可用性
Kafka集群如何配置高可用性
670 1
|
消息中间件 分布式计算 监控
大数据-78 Kafka 集群模式 集群的应用场景与Kafka集群的搭建 三台云服务器
大数据-78 Kafka 集群模式 集群的应用场景与Kafka集群的搭建 三台云服务器
428 6
|
消息中间件 存储 Kafka
2024最全Kafka集群方案汇总
Apache Kafka 是一个高吞吐量、可扩展、可靠的分布式消息系统,广泛应用于数据驱动的应用场景。Kafka 支持集群架构,具备高可用性和容错性。其核心组件包括 Broker(服务器实例)、Topic(消息分类)、Partition(有序消息序列)、Producer(消息发布者)和 Consumer(消息消费者)。每个分区有 Leader 和 Follower,确保数据冗余和高可用。Kafka 2.8+ 引入了不依赖 Zookeeper 的 KRaft 协议,进一步简化了集群管理。常见的集群部署方案包括单节点和多节点集群,后者适用于生产环境以确保高可用性。
1119 0
|
消息中间件 Kafka 测试技术
【Kafka揭秘】Leader选举大揭秘!如何打造一个不丢失消息的强大Kafka集群?
【8月更文挑战第24天】Apache Kafka是一款高性能分布式消息系统,利用分区机制支持数据并行处理。每个分区含一个Leader处理所有读写请求,并可有多个副本确保数据安全与容错。关键的Leader选举机制保障了系统的高可用性和数据一致性。选举发生于分区创建、Leader故障或被手动移除时。Kafka提供多种选举策略:内嵌机制自动选择最新数据副本为新Leader;Unclean选举快速恢复服务但可能丢失数据;Delayed Unclean选举则避免短暂故障下的Unclean选举;Preferred选举允许基于性能或地理位置偏好指定特定副本为首选Leader。
693 5
|
消息中间件 运维 数据管理
Kafka 如何基于 KRaft 实现集群最终一致性协调
Kafka 3.3.1 引入了 KRaft 元数据管理组件,替代 Zookeeper,以简化集群一致性维护,支持更大规模集群并减轻运维复杂性。在 Zookeeper 模式下,需同时运维 ZK 和 Broker,而 KRaft 模式仅需 3 个节点即可构成最小生产集群,且通信协调基于 Raft 协议,增强了一致性。KRaft 模式中,Controller 使用单线程处理请求,通过 KRaft 保持内存状态与多节点一致性。此外,Broker 根据 KRaft 记录更新元数据,实现声明式管理,提高集群协调效率。KRaft 的引入是集群协调机制的演进,采用事件驱动模型实现元数据的一致性。
1270 1
Kafka 如何基于 KRaft 实现集群最终一致性协调

热门文章

最新文章