ToB企服应用市场:ToB评测及商务社交产业平台

标题: Kafka——两种集群搭建详解 [打印本页]

作者: 花瓣小跑 时间: 2024-9-7 11:33
标题: Kafka——两种集群搭建详解
1、简介

Kafka是一个能够支持高并发以及流式消息处理的消息中间件，而且Kafka天生就是支持集群的，本日就重要来先容一下如何搭建Kafka集群。
Kafka现在支持利用Zookeeper模式搭建集群以及KRaft模式（即无Zookeeper）模式这两种模式搭建集群，这两种模式各有各的好处，本日就来分别先容一下这两种方式
1.1、Kafka集群中的节点范例

一个Kafka集群是由下列几种范例的节点构成的，它们充当着不同的作用：

Broker节点：即代理节点，是Kafka中的工作节点，充当消息队列的脚色，负责储存和处理消息，每个Broker都是一个独立的Kafka服务器，可以在不同的呆板上运行，除此之外Broker还负责分区（partition）的管理，将主题（topic）划分为多个分区，并分布在集群的不同Broker上
Controller节点：即控制器节点，是集群中的特别节点，负责储存和管理整个集群元数据和状态，它能够监控整个集群中的Broker，在需要时还能够进行平衡操作
混淆节点：即同时担任Broker和Controller节点脚色的节点

1.2、两重模式的搭建方式

Zookeeper模式集群
KRaft模式集群

2、Zookeeper模式集群

这是一种比较简单，相对“传统”的搭建方式了！在这种模式下，每个Kafka节点都是依靠于Zookeeper的，利用Zookeeper存储集群中全部节点的元数据。
只要全部的Kafka节点毗连到同一个Zookeeper上面（或者同一个Zookeeper集群），这些Kafka节点就构成了一个集群。以是说就算是只有一个Kafka节点在运行，这一个节点也可以称作一个集群。
在Zookeeper模式集群中，Zookeeper节点（或者集群）就充当了Controller的脚色，而全部的Kafka节点就充当着Broker的脚色。
下面就来先容一下搭建过程，这里在1台主机上分别运行Zookeeper和Kafka来模拟一个集群，一共一个Zookeeper节点和三个Kafka节点构成，如下：
节点名地址和端口Zookeeper节点localhost:2181Kafka节点1localhost:9092Kafka节点1localhost:9093Kafka节点1localhost:9094 1、搭建Zookeeper
首先我们要运行起一个Zookeeper节点，这里就不再赘述Zookeeper节点如何搭建了，搭建可以查看官方文档，或者利用Docker的方式搭建。
搭建完成并运行Zookeeper之后，我们会把全部的Kafka节点都配置到这一个Zookeeper节点上。
2、配置并运行全部Kafka节点
修改每台假造机的Kafka目录中的配置文件，配置文件位于解压的Kafka文件夹中的config/server.properties，对应的三个配置文件如下：
server1.properties

# 每个节点的id，不要不相同的整数
broker.id=1
# 存储位置
log.dirs=/tmp/kafka-logs/cluster/log1
# zookeeper集群的话，多个地址用逗号分割
zookeeper.connect=localhost:2181
# zookeeper连接超时时间
zookeeper.connection.timeout.ms=18000
# 外网暴露
advertised.listeners=PLAINTEXT://localhost:9092
# 内网端口
listeners=PLAINTEXT://localhost:9092

复制代码

server2.properties

# 每个节点的id，不要不相同的整数
broker.id=2
# 存储位置
log.dirs=/tmp/kafka-logs/cluster/log2
# zookeeper集群的话，多个地址用逗号分割
zookeeper.connect=localhost:2181
# zookeeper连接超时时间
zookeeper.connection.timeout.ms=18000
# 外网暴露
advertised.listeners=PLAINTEXT://localhost:9093
# 内网端口
listeners=PLAINTEXT://localhost:9093

复制代码

server3.properties

# 每个节点的id，不要不相同的整数
broker.id=3
# 存储位置
log.dirs=/tmp/kafka-logs/cluster/log3
# zookeeper集群的话，多个地址用逗号分割
zookeeper.connect=localhost:2181
# zookeeper连接超时时间
zookeeper.connection.timeout.ms=18000
# 外网暴露
advertised.listeners=PLAINTEXT://localhost:9094
# 内网端口
listeners=PLAINTEXT://localhost:9094

复制代码

三台假造机配置完成后，分别利用终端进入到Kafka目录下并启动，执行下列命令：

./kafka-server-start.sh -daemon ../config/cluster/server1.properties
./kafka-server-start.sh -daemon ../config/cluster/server2.properties
./kafka-server-start.sh -daemon ../config/cluster/server3.properties

复制代码

到此，整个集群就搭建完成了。
3、测试
先在kafka1的端口上面再开一个终端并进入Kafka目录，执行下列命令创建cluster-topic，共3个分区，每个人去都分配3个副本：

./kafka-topics.sh --bootstrap-server localhost:9092 --create --topic cluster-topic --partitions 3 --replication-factor 3

复制代码

然后在kafka2的端口查询该topic：

./kafka-topics.sh --bootstrap-server localhost:9093 --describe --topic cluster-topic

复制代码

显而易见，该topic下有3个分区，每个分区有三个副本。每个分区的leader分别是1，2，3，表明kafka将该topic的3分区均匀地在3台broker上进行了分配。
删除分区：

./kafka-topics.sh --bootstrap-server localhost:9093 --delete --topic cluster-topic

复制代码

3、KRaft模式集群

在上述传统方案中，Kafka需要依靠Zookeeper完成元数据存放和共享，这样也就暴袒露了一些题目：

搭建Kafka集群时还需要额外搭建Zookeeper，增长了运维成本
Zookeeper是强划一性的组件（符合CP理论），如果集群中数据发生变革，那么必须要比及别的节点都同步，至少超过一半同步完成，这样节点数多性能差

KRaft模式是新版本Kafka中推出的集群模式，这种模式下就完全不需要Zookeeper了！只需要数个Kafka节点就可以直接构成集群，在这时集群中的Kafka节点既有大概是Controller节点也大概是Broker节点，在这个模式中，我们不仅可以手动配置某个节点的脚色（是Controller还是Broker），还可以使其同时担任Broker和Controller脚色（混淆节点）。
在KRaft模式中，集群的节点会通过投票选举的方式，选择出一个重要的Controller节点，这个节点也称作领导者，它将负责维护整个集群的元数据和状态信息，那么别的的Controller节点或者混淆节点就称之为追随者，它们会从领导者同步集群元数据和状态信息。如果领导者宕机了，全部的节点会重新投票选举一个新的领导者。
在选举过程中，全部的节点都会到场投票过程，而候选节点只会是Controller节点或者混淆节点（即Broker节点不会被选举为领导者）。
需要注意的是，在默认情况下Kafka集群中的Broker节点和Controller节点通常会监听不同的端口：

Broker节点是Kafka集群中的数据节点（消息队列），它们负责吸收客户端的消息和传递消息给客户端，默认情况下，每个Broker节点会监听9092端口，该端口用于与客户端进行通讯，客户端可以将消息发送到这个端口，或者从这个端口吸收消息，这个端口可以称作客户端通讯端口
Controller节点是Kafka集群中的控制器节点，负责管理集群的状态和元数据，Controller节点监听的端口通常是9093，该端口用于集群中其他节点获取元数据或在混淆节点选举新的Controller时进行通讯，通过该端口，其他节点可以与Controller节点交互，获取集群的元数据信息或到场控制器的选举过程，这个端口可以称作控制器端口
混淆节点（即同时担任Broker和Controller脚色的节点）中，这两个端口都会被利用，默认情况下混淆节点将监听9092端口吸收和传递消息给客户端，并监听9093端口用于与其他节点进行元数据交换和控制器选举通讯，可见混淆节点会同时利用两个端口分别作为客户端通讯端口与控制器端口

以是需要根据实际情况配置网络设置和防火墙规则，以确保Kafka集群中的节点能够在精确的端口上进行通讯。上述提到的两种端口也是可以修改的，当然不建议修改。
同样地，就算是你只是搭建了一个Kafka节点，这一个节点也仍然被视为一个Kafka集群，而且KRaft模式下如果只需要建立一个节点，那么这个节点必须是混淆节点。
单台主机模拟搭建三个Kafka节点构成的KRaft模式集群如下：
节点名地址节点范例客户端通讯端口控制器端口Kafka节点1localhost混淆节点90929093Kafka节点2localhost混淆节点90949095Kafka节点3localhost混淆节点90969097 1、修改配置文件
在KRaft模式下，配置文件位于Kafka目录中的config/kraft/server.properties，利用文本编辑器打开并找到下列配置以修改：

node.id 表现这个节点的id，一个集群中每个节点id不能重复，需要是不小于1的整数，这里三台假造机的配置分别为1，2和3（类似上述Zookeeper的broker.id配置）
controller.quorum.voters 设定投票者列表，即需要配置全部的Controller节点id及其地址端口，配置格式为节点1的id@节点1地址:节点1端口,节点2的id@节点2地址:节点2端口,节点3的id@节点3地址:节点3端口…，这里的端口需要是控制器端口，默认都是9093，上面也提到过了，默认不需要修改
advertised.listeners 表现这个Kafka节点的外网地址，这里分别配置为PLAINTEXT://localhost:9092，PLAINTEXT://localhost:9094和PLAINTEXT://localhost:9096（和上述Zookeeper模式中的一样，实际在服务器上搭建时替换为服务器的外网地址或者域名）
process.roles 表现设定这个节点的范例，设定为broker表现设定这个节点为Broker节点，同样地设定controller表现设定为Controller节点，默认是broker,controller表现这个节点会主动切换节点范例

server1.properties

# 节点类型，默认为混合节点
process.roles=broker,controller
# 节点id，为不小于1的整数
node.id=1
# 投票者列表：nodeId+地址端口
controller.quorum.voters=1@localhost:9093,2@localhost:9095,3@localhost:9097
# 内网地址
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
inter.broker.listener.name=PLAINTEXT
# 外网地址
advertised.listeners=PLAINTEXT://localhost:9092
controller.listener.names=CONTROLLER
log.dirs=/tmp/kraft-combined-logs/log1

复制代码

server2.properties

# 节点类型，默认为混合节点
process.roles=broker,controller
# 节点id，为不小于1的整数
node.id=2
# 投票者列表：nodeId+地址端口
controller.quorum.voters=1@localhost:9093,2@localhost:9095,3@localhost:9097
# 内网地址
listeners=PLAINTEXT://:9094,CONTROLLER://:9095
inter.broker.listener.name=PLAINTEXT
# 外网地址
advertised.listeners=PLAINTEXT://localhost:9094
controller.listener.names=CONTROLLER
log.dirs=/tmp/kraft-combined-logs/log2

复制代码

server3.properties

# 节点类型，默认为混合节点
process.roles=broker,controller
# 节点id，为不小于1的整数
node.id=3
# 投票者列表：nodeId+地址端口
controller.quorum.voters=1@localhost:9093,2@localhost:9095,3@localhost:9097
# 内网地址
listeners=PLAINTEXT://:9096,CONTROLLER://:9097
inter.broker.listener.name=PLAINTEXT
# 外网地址
advertised.listeners=PLAINTEXT://localhost:9096
controller.listener.names=CONTROLLER
log.dirs=/tmp/kraft-combined-logs/log3

复制代码

2、生成集群ID并利用集群ID格式化数据目录
在KRaft模式下，一个集群需要设定一个id，我们可以利用自带的命令生成，先进入上述恣意一台假造机并利用终端进入Kafka目录中，执行下列命令生成一个UUID：

bin/kafka-storage.sh random-uuid

复制代码

这里记录下这个ID以备用。kilMbKEoRUq3Ha6nruW6Aw
这个集群ID毕竟上是一个长度16位的字符串通过Base64编码后得来的，因此你也可以不利用上述命令，直接自定义一个16位长度的纯英文和数字组成的字符串，然后将这个字符串编码为Base64格式作为这个集群ID也可以。可以利用菜鸟工具中的在线Base64编码工具。
然后，分别执行下列命令，配置集群元数据：

kafka-storage.sh format -t 生成的集群ID -c ../config/kraft/cluster/server1.properties
kafka-storage.sh format -t kilMbKEoRUq3Ha6nruW6Aw -c ../config/kraft/cluster/server2.properties
kafka-storage.sh format -t kilMbKEoRUq3Ha6nruW6Aw -c ../config/kraft/cluster/server3.properties

复制代码

3、启动Kafka集群
利用终端，分别执行下列命令：

kafka-server-start.sh -daemon ../config/kraft/cluster/server1.properties
kafka-server-start.sh -daemon ../config/kraft/cluster/server2.properties
kafka-server-start.sh -daemon ../config/kraft/cluster/server3.properties

复制代码

4、创建topic测试
先在kafka1的端口(9092)上面再开一个终端并进入Kafka目录，执行下列命令创建cluster-topic，共3个分区，每个人去都分配3个副本：

./kafka-topics.sh --bootstrap-server localhost:9092 --create --topic cluster-topic --partitions 3 --replication-factor 3

复制代码

然后在kafka2的端口(9094)查询该topic：

./kafka-topics.sh --bootstrap-server localhost:9094 --describe --topic cluster-topic

复制代码

在kafka3的端口(9096)删除分区：

./kafka-topics.sh --bootstrap-server localhost:9096 --delete --topic cluster-topic

复制代码

可见集群节点之间可以互相通讯。
4、告急配置先容

4.1、listeners

这个配置项用于指定Kafka服务器监听客户端毗连的地址和端口，当 Kafka 服务器启动时，它将监听listeners配置项中指定的地址和端口，等待客户端的毗连哀求。
一样平常情况下这个配置以PLAINTEXT://或者CONTROLLER://开头，意义如下：

若这个节点是Broker节点，则以PLAINTEXT://开头
若这个节点是Controller节点，则以CONTROLLER://开头
若这个节点是混淆节点，则需要同时配置两者开头的地址

这个配置项通常不需要修改，下面给出几个配置示例：

PLAINTEXT://:9092 本节点作为Broker节点，监听本机全部可用网卡的9092端口（利用9092端口作为客户端通讯端口），也是默认配置
PLAINTEXT://127.0.0.1:9092 本节点作为Broker节点，监听当地的9092端口，这样仅接受来自当地的哀求
CONTROLLER://:10000 本节点作为Controller节点，监听本机全部可用网卡的10000端口（利用10000端口作为控制器端口）
PLAINTEXT://:9092,CONTROLLER://:9093 本节点作为混淆节点，监听本机全部可用网卡的9092和9093端口，其中9092作为客户端通讯端口，9093作为控制器端口

4.2、advertise.listeners

这个配置容易和listeners混淆，毕竟上它们是有较大的区别的。
该配置项指定Kafka服务器广播给客户端的地址和端口，通常配置为Kafka所在服务器的外网地址。
当客户端（生产者或消费者）实验毗连到Kafka服务器时，它首先会获取Kafka服务器广播的地址和端口，也就是advertise.listeners配置所指定的地址和端口，然后才会利用advertise.listeners配置所指定的地址和端口来建立与Kafka服务器的毗连。
相信这时大家会有个疑问：既然客户端要毗连Kafka（例如Spring Boot集成Kafka客户端），那肯定是已经知道了Kafka对外的地址端口了，那为什么毗连的时间还需要获取一下广播的地址端口再进行毗连呢？这样是不是有一些多此一举？
毕竟上，Kafka设计这个配置是为了解决下面较为复杂的网络场景：

多网络接口的主机部署：在一个多网络接口的主机部署Kafka时，Kafka服务器大概会监听多个地址和端口，这些地址和端口大概与客户端实际访问的地址和端口不同，advertise.listeners允许服务器指定一个公开的、可访问的地址和端口，以便客户端能够精确毗连
NAT/代理环境：在某些网络环境下，Kafka服务器位于一个私有网络中，客户端位于一个公共网络中，两者之间大概存在网络地址转换（NAT）或代理，在这种情况下，Kafka服务器的内部地址和端口对客户端来说是不可访问的。通过利用advertise.listeners，Kafka服务器可以将一个公共地址和端口广播给客户端，使得客户端能够通过公共网络毗连到服务器
容器环境：例如你把Kafka放在Docker容器中运行，按照默认配置，Kafka服务端只会监听容器网络的9092端口，我们知道外部不能直接访问容器的网络，而是需要利用网络映射，假设你把Kafka容器的9092端口映射至了宿主机9095端口，也就是说外部需要通过9095端口访问到Kafka容器的9092端口，那么你就配置advertise.listeners为PLAINTEXT://服务器外网地址:9095，客户端就可以精确访问容器中的Kafka了

总之，这个配置设置为Kafka服务器所在的外网地址即可！例如PLAINTEXT://69.54.112.239:9092。
4.3、process.roles

这是KRaft模式下专门的配置，用于配置这个节点的范例，可以配置为下列值：

broker 表现这个节点是Broker节点，充当消息队列的脚色
controller 表现这个节点是Controller节点，充当元数据存放和管理的脚色
broker,controller 表现这个节点同时担任Broker和Controller的脚色，也称作混淆节点
如果没有配置这个选项，则Kafka会以Zookeeper模式运行。

这里有下列注意事项：

如果设定节点为controller：
- 则不能配置advertised.listeners，可以将其解释掉或者删掉
- listeners需要配置为CONTROLLER://开头，建议配置为CONTROLLER://:9093
如果设定节点为broker：
- 则需要配置advertised.listeners为服务器外网地址和端口，这和Zookeeper模式中雷同
- listeners需要配置为PLAINTEXT://开头，建议配置为PLAINTEXT://:9092
如果设定节点为混淆节点：
- 同样需要配置advertised.listeners为服务器外网地址和端口
- listeners需要同时配置CONTROLLER://和PLAINTEXT://，建议配置为PLAINTEXT://:9092,CONTROLLER://:9093

在开发环境或者小规模集群，可以全部利用混淆节点，如果是生产环境就建议设定好每个节点的范例了！而且通常需要先启动Controller节点再启动Broker节点。
毕竟上，我们发现Kafka的KRaft配置目录config/kraft下有三个配置文件，其中server.properties是混淆节点的配置模板，而broker.properties和controller.properties分别是Broker节点和Controller节点的配置模板，大家如果要设定节点范例，可以直接利用对应的配置文件，将对应配置文件需要修改的部分修改一下，然后将上述格式化数据目录命令和启动命令中的配置文件路径改变一下即可，这样可以省略我们设定process.roles和listeners或者控制器节点删除advertise.listeners配置的操作。
4.4、controller.quorum.voters

该配置项用于配置集群中Controller节点选举过程中的投票者，集群中全部的Controller节点都需要被罗列在这个配置项中，其配置格式为id1@host1:port1,id2@host2:port2,id3@host3:port3...。
有的同学大概认为这里需要把集群中全部节点都写进去，毕竟上这是错误的，这里只需要写全部的Controller节点和混淆节点的id、地址和端口即可，这个配置中配置的端口当然是控制器端口。
上述集群搭建的例子中，由于全部的节点都是混淆节点，因此就全部写在其中了！如果我们手动设定每个节点的范例，例如：
节点名节点id地址服务器通讯端口控制器端口节点范例Kafka节点11kafka1/9093ControllerKafka节点22kafka29092/BrokerKafka节点33kafka39092/Broker 那么全部节点的controller.quorum.voters都需要配置为1@kafka1:9093。
毕竟上，全部的节点都是通过这个配置中的节点列表，来得知全部的控制器节点信息（以获取集群元数据）并得到投票候选者的，因此集群中全部节点，不论是Broker还是Controller，还是混淆节点，都需要配置这一项。
4.5、别的配置

除了上述我们涉及到的一些配置之外，还有下列配置大家可以进行修改：

socket.send.buffer.bytes 每次发送的数据包的最大巨细（单元：字节）
socket.receive.buffer.bytes 每次吸收的数据包的最大巨细（单元：字节）
socket.request.max.bytes 吸收的最大哀求巨细（单元：字节）
num.partitions 每个Topic的默认分区数

上述无论是哪个模式的集群，都可以在配置文件中找到这些配置，如果找不到可手动参加。除了修改配置文件之外，我们还可以在启动Kafka的命令中指定配置和值，例如：

bin/kafka-server-start.sh config/server.properties --override zookeeper.connect=127.0.0.1:2181 --override broker.id=1

复制代码

上述命令在启动时通过命令指定了zookeeper.connect配置值为127.0.0.1:2181，以及broker.id为1，可见在后面追加–override 配置名=值即可，注意命令行中指定的配置值会覆盖掉配置文件中的配置值！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)