kafka基础入门（3）：kafka Broker

最新推荐文章于 2024-05-17 14:25:55 发布

THE WHY

最新推荐文章于 2024-05-17 14:25:55 发布

阅读量830

点赞数

分类专栏： kafka 大数据文章标签： kafka 服务器分布式大数据 Powered by 金山文档

本文链接：https://blog.csdn.net/qq_51235856/article/details/128857855

版权

大数据同时被 2 个专栏收录

65 篇文章 5 订阅

订阅专栏

kafka

4 篇文章 1 订阅

订阅专栏

Kafka Broker

zookeeper存储kafka相关信息

例：

查看kafka信息的相关zk指令

查看当前已启动的broker：ls /kafka/brokers/ids

查看当前controller：get /kafka/controller

查看各个分区的leader和可用服务器相关信息：get /kafka/brokers/topics/first/partitions/0/state

0指的是broker id

broker工作流程

1）broker启动后在zk中注册：集群中哪一台机器的kafka启动，就在zk中注册其对应的broker id

2）最先注册的broker中的controller负责进行leader选举

6）信息同步是为了controller挂掉之后，替补的controller能正常进行leader选举

10）按例，broker1挂掉了，controller从zk中获取到当前的isr信息，从中剔除1号id，然后按照选举规则选举出新的leader，进而更新zk

broker相关参数

所有的参数配置都在/config/server.properties中进行设置；（大部分都没有默认值，需要手动添加）

broker节点服役和退役

新节点服役：

1.启动新的broker，设置broker id

2.创建一个要均衡的主题：vim topics-to-move.json（主题名自拟）

3.向其中写入内容：

{

"topics": [

{"topic": "first"}

"version": 1

}

4.生成一个负载均衡的计划：

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --topics-to-move-json-file

topics-to-move.json --broker-list "0,1,2,3" --generate

--topics-to-move-json-file：需要进行均衡的主题

--broker-list：共有哪些broker参与均衡

5.创建副本存储计划（所有副本存储在 broker0、broker1、broker2、broker3 中）

新建一个文件：vim increase-replication-factor.json

将上面新生成的内容添加到文件中去

6.执行副本存储计划

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file

increase-replication-factor.json --execute

--reassignment-json-file：存放副本存储计划的文件名

7.验证副本存储计划：

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file

increase-replication-factor.json --verify

新节点退役：

与节点服役的流程相同，区别在于第4步生成负载均衡计划的时候，需要修改broker-list

执行完副本存储计划之后，关闭相关服务器即可

Kafka 副本

副本的作用在于提高数据可靠性；Kafka 默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率

副本分类：

Kafka 中副本分为：Leader 和 Follower。Kafka 生产者只会把数据发往 Leader，然后 Follower 找 Leader 进行同步数据

副本组成：

Kafka 分区中的所有副本统称为 AR（Assigned Repllicas）

AR = ISR（和 Leader 保持同步的 Follower 集合）+ OSR（表示 Follower 与 Leader 副本同步时，延迟过多的副本）

leader选举示例

1.启动broker id 为0,1,2的三台机器，创建副本和分区数均为3的topic：testar

查看其信息：

2.关闭broker id为3的服务器：

查看该topic的信息；

可以验证leader的选举规则

分区副本分配策略

分区数大于服务器台数的情况：

例：4台服务器，16个分区（3个副本）：

这种情况下每台服务器不只存储一个分区的数据

手动调整副本存储策略：

与服务器上下线类似，需要执行副本存储计划

首先还是创建文件：

{

"version":1,

"partitions":[{"topic":"three","partition":0,"replicas":[0,1]},

{"topic":"three","partition":1,"replicas":[0,1]},

{"topic":"three","partition":2,"replicas":[1,0]},

{"topic":"three","partition":3,"replicas":[1,0]}]

}

向文件中写入副本存储计划，需要注意的是，这里的副本存储计划是手动设置的，不是自动生成的；

如上的内容就表明了3个分区的所有副本全部存储到0和1服务器中；

之后执行该副本存储计划即可

通过查看topic的详细信息（--describe）即可验证

Leader 和 Follower 故障处理细节

首先要明确两个概念：

LEO（Log End Offset）：每个副本的最后一个offset，LEO其实就是最新的offset + 1。

HW（High Watermark）：所有副本中最小的LEO

Follower故障

Leader故障

注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复

生产经验

Leader Partition 负载平衡

正常情况下，Kafka本身会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机的broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡

增加副本因子

在生产环境当中，由于某个主题的重要等级需要提升，可以增加副本

1.创建topic：

bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --create --partitions 3 --replication-factor 1 --topic four

可以看到只有一个副本

2.创建副本存储计划，手动写入要增加的副本

示例：

{"version":1,"partitions":[{"topic":"four","partition":0,"replica

s":[0,1,2]},{"topic":"four","partition":1,"replicas":[0,1,2]},{"t

opic":"four","partition":2,"replicas":[0,1,2]}]}

通过手动的修改，将副本数增加到了3个，在其他两台服务器上也进行副本的备份

3.执行副本存储计划即可

文件存储机制

kafka的每个partition对应于一个log文件，该log文件中存储的就是Producer生产的数据。Producer生产的数据会被不断追加到该log文件末端，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment（默认大小为1G）；每个segment包括：“.index”文件、“.log”文件和.timeindex等文件

segment命名规则：topic名称+分区序号

例：