1.Kafka Broker 工作流程
(1)zookeeper中存储的kafka信息
1)启动 Zookeeper 客户端。
[zrclass@hadoop102 zookeeper-3.5.7]$ bin/zkCli.sh
2)通过 ls 命令可以查看 kafka 相关信息。
[zk: localhost:2181(CONNECTED) 2] ls /kafka
(2)Kafka中两种Leader的概念
kafka集群中有2个种leader,一种是broker的leader即controller leader,还有一种就是partition中的副本的leader
1)Controller leader
当broker启动的时候,都会创建KafkaController对象,但是集群中只能有一个leader对外提供服务,这些每个节点上的KafkaController会在指定的zookeeper路径下创建临时节点,只有第一个成功创建的节点KafkaController才可以成为leader,其余的都是follower。当leader故障后,所有的follower会收到通知,再次竞争在该路径下创建节点从而选举新的leader
2) Replication leader
为了实现高可用,保证集群中的某个节点发生故障时,且节点上的partition 数据不丢失且kafka能正常提供服务,kafka提供副本机制,topic内的每个分区可以设置若干个副本(包含leader和follower); 消息的读写只会发生在leader副本上。
(3)Kafka Broker 总体工作流程
(4)模拟 Kafka 上下线,Zookeeper中数据变化
1)查看/kafka/brokers/ids 路径上的节点。
[zk: localhost:2181(CONNECTED) 2] ls /kafka/brokers/ids
[0, 1, 2]
2)查看/kafka/controller 路径上的数据。
[zk: localhost:2181(CONNECTED) 15] get /kafka/controller
{"version":1,"brokerid":0,"timestamp":"1637292471777"}
3)查看/kafka/brokers/topics/first/partitions/0/state 路径上的数据。
[zk: localhost:2181(CONNECTED) 16] get /kafka/brokers/topics/first/partitions/0/state
{"controller_epoch":24,"leader":0,"version":1,"leader_epoch":18," isr":[0,1,2]}
4)停止 hadoop104 上的 kafka。
[atguigu@hadoop104 kafka]$ bin/kafka-server-stop.sh
5)再次查看/kafka/brokers/ids 路径上的节点。
[zk: localhost:2181(CONNECTED) 3] ls /kafka/brokers/ids
[0, 1]
6)再次查看/kafka/controller 路径上的数据。
[zk: localhost:2181(CONNECTED) 15] get /kafka/controller
{"version":1,"brokerid":0,"timestamp":"1637292471777"}
7)再次查看/kafka/brokers/topics/first/partitions/0/state 路径上的数据。
[zk: localhost:2181(CONNECTED) 16] get /kafka/brokers/topics/first/partitions/0/state
{"controller_epoch":24,"leader":0,"version":1,"leader_epoch":18," isr":[0,1]}
(5)Broker重要参数
2.kafka副本
(1)Kafka 副本作用:提高数据可靠性。
(2)Kafka 默认副本 1 个,生产环境一般配置为 2 个,保证数据可靠性;太多副本会 增加磁盘存储空间,增加网络上数据传输,降低效率。
(3)Kafka 中副本分为:Leader 和 Follower。Kafka 生产者只会把数据发往 Leader, 然后 Follower 找 Leader 进行同步数据。
(4)Kafka 分区中的所有副本统称为 AR(Assigned Repllicas)。
AR = ISR + OSR
ISR, In-Sync Replicas (同步副本集 ),表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信请求或同步数据,则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms 参数设定,默认 30s。Leader 发生故障之后,就会从 ISR 中选举新的 Leader。
OSR, ( Out-Sync Relipcas ),表示 Follower 与 Leader 副本同步时,延迟过多的副本。
3.kafka分区副本的选举流程
(1)Kafka选举流程
Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader,负责管理集群 broker 的上下线,所有 topic 的分区副本分配和副本 Leader 选举等工作。 Controller 的信息同步工作是依赖于 Zookeeper 的。
(2)模拟kafka的Follewer和Leader故障
1)创建一个新的 topic,4 个分区,4 个副本
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --create --topic test --partitions 4 --replication-factor 4
Created topic test.
2)查看 Leader 分布情况
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic test
Topic: test TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: test Partition: 0 Leader: 3 Replicas: 3,0,2,1 Isr: 3,0,2,1
Topic: test Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,2,3,0
Topic: test Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,3,1,2
Topic: test Partition: 3 Leader: 2 Replicas: 2,1,0,3 Isr: 2,1,0,3
3)停止掉 hadoop105 的 kafka 进程,并查看 Leader 分区情况
如果 Follower 长时间未向 Leader 发送通信请求或同步数据,则该 Follower 将被踢出 ISR
[zrclass@hadoop105 kafka]$ bin/kafka-server-stop.sh
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic test
Topic: test TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: test Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,2,1
Topic: test Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,2,0
Topic: test Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,1,2
Topic: test Partition: 3 Leader: 2 Replicas: 2,1,0,3 Isr: 2,1,0
4)停止掉 hadoop104 的 kafka 进程,并查看 Leader 分区情况
如果 Follower 长时间未向 Leader 发送通信请求或同步数据,则该 Follower 将被踢出 ISR
[zrclass@hadoop104 kafka]$ bin/kafka-server-stop.sh
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic test
Topic: test TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: test Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,1
Topic: test Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,0
Topic: test Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,1
Topic: test Partition: 3 Leader: 1 Replicas: 2,1,0,3 Isr: 1,0
5)启动 hadoop105 的 kafka 进程,并查看 Leader 分区情况
Follower重新向leader发送通信请求或同步数据,Follower重新加入到ISR
[zrclass@hadoop105 kafka]$ bin/kafka-server-start.sh -daemon config/server.properties
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic test
Topic: test TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: test Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,1,3
Topic: test Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,0,3
Topic: test Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,1,3
Topic: test Partition: 3 Leader: 1 Replicas: 2,1,0,3 Isr: 1,0,3
6)启动 hadoop104 的 kafka 进程,并查看 Leader 分区情况
Follower重新向leader发送通信请求或同步数据,Follower重新加入到ISR
[zrclass@hadoop104 kafka]$ bin/kafka-server-start.sh -daemon config/server.properties
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic test
Topic: test TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: test Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,1,3,2
Topic: test Partition: 1 Leader: 1 Replicas: 1,2,3,0 Isr: 1,0,3,2
Topic: test Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,1,3,2
Topic: test Partition: 3 Leader: 1 Replicas: 2,1,0,3 Isr: 1,0,3,2
7)停止掉 hadoop103 的 kafka 进程,并查看 Leader 分区情况
Leader 发生故障之后,就会从 ISR 中选举新的 Leader,按照AR(分区中所有副本)的排列顺序轮询,即控制台中Replicas所展示的顺序轮询
[zrclass@hadoop103 kafka]$ bin/kafka-server-stop.sh
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic test
Topic: test TopicId: awpgX_7WR-OX3Vl6HE8sVg PartitionCount: 4 ReplicationFactor: 4
Configs: segment.bytes=1073741824
Topic: test Partition: 0 Leader: 0 Replicas: 3,0,2,1 Isr: 0,3,2
Topic: test Partition: 1 Leader: 2 Replicas: 1,2,3,0 Isr: 0,3,2
Topic: test Partition: 2 Leader: 0 Replicas: 0,3,1,2 Isr: 0,3,2
Topic: test Partition: 3 Leader: 2 Replicas: 2,1,0,3 Isr: 0,3,2
(3)Leader 和 Follower 故障处理细节
1)Follower故障处理细节
2)Leader故障处理细节
(4)kafka分区副本的分配
如果 kafka 服务器只有 4 个节点,那么设置 kafka 的分区数大于服务器台数,在 kafka
底层如何分配存储副本呢?
1)创建 16 分区,3 个副本
创建一个新的 topic,名称为 second。
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --create --partitions 16 --replication-factor 3 --topic second
查看分区和副本情况。
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server
hadoop102:9092 --describe --topic second
Topic: second4 Partition: 0 Leader: 0 Replicas: 0,1,2 Isr: 0,1,2
Topic: second4 Partition: 1 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Topic: second4 Partition: 2 Leader: 2 Replicas: 2,3,0 Isr: 2,3,0
Topic: second4 Partition: 3 Leader: 3 Replicas: 3,0,1 Isr: 3,0,1
Topic: second4 Partition: 4 Leader: 0 Replicas: 0,2,3 Isr: 0,2,3
Topic: second4 Partition: 5 Leader: 1 Replicas: 1,3,0 Isr: 1,3,0
Topic: second4 Partition: 6 Leader: 2 Replicas: 2,0,1 Isr: 2,0,1
Topic: second4 Partition: 7 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Topic: second4 Partition: 8 Leader: 0 Replicas: 0,3,1 Isr: 0,3,1
Topic: second4 Partition: 9 Leader: 1 Replicas: 1,0,2 Isr: 1,0,2
Topic: second4 Partition: 10 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
Topic: second4 Partition: 11 Leader: 3 Replicas: 3,2,0 Isr: 3,2,0
Topic: second4 Partition: 12 Leader: 0 Replicas: 0,1,2 Isr: 0,1,2
Topic: second4 Partition: 13 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Topic: second4 Partition: 14 Leader: 2 Replicas: 2,3,0 Isr: 2,3,0
Topic: second4 Partition: 15 Leader: 3 Replicas: 3,0,1 Isr: 3,0,1
总结
1.kafka的副本数量不能大于broker节点数量。kafka的副本数量和HDFS的副本数量是有区别的。
(1)HDFS的副本数量表示为最大副本数量,当DataNode节点数量小于设置的副本数量时没有任何问题,当新增DataNode时候如果副本数量没达到要求会自动复制副本。
(2)而kafka的副本数量表示为该topic的副本数量,当副本数量大于broker节点数量时会报错,这是因为分区是以目录存储在各个broker节点的data目录下,命名为:topicName-分区编号。当副本数量大于broker节点时就表示在同一个Broker节点的data目录下有两个一样的文件夹,这是不允许的。
2.kafka的分区数量可以大于broker节点数量,当分区数量大于broker节点数量时,在broker节点的data目录下会有同一个topic的两个分区的数据,如:topicName-0,topicName-1。
(5)手动调整分区副本存储
在生产环境中,每台服务器的配置和性能不一致,但是Kafka只会根据自己的代码规则创建对应的分区副本,就会导致个别服务器存储压力较大。所有需要手动调整分区副本的存储。
需求:创建一个新的topic,4个分区,两个副本,名称为three。将 该topic的所有副本都存储到broker0和broker1两台服务器上。
手动调整分区副本存储的步骤如下:
1)创建一个新的 topic,名称为 three。
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --create --partitions 4 --replication-factor 2 --topic three
2)查看分区副本存储情况。
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic three
3)创建副本存储计划(所有副本都指定存储在 broker0、broker1 中)。
[zrclass@hadoop102 kafka]$ vim increase-replication-factor.json
输入如下内容:
{
"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]}
]
}
4)执行副本存储计划。
[zrclass@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --execute
5)验证副本存储计划。
[zrclass@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --verify
6)查看分区副本存储情况。
[zrclass@hadoop102 kafka]$ bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic three
4.kafka文件存储
(1)topic数据存储机制
Topic是逻辑上的概念,而partition是物理上的概念,每个partition对应于一个log文件,该log文件中存储的就是Producer生产的数 据。Producer生产的数据会被不断追加到该log文件末端,为防止log文件过大导致数据定位效率低下,Kafka采取了分片和索引机制, 将每个partition分为多个segment。每个segment包括:“.index”文件、“.log”文件和.timeindex等文件。这些文件位于一个文件夹下,该 文件夹的命名规则为:topic名称+分区序号,例如:first-0。
(2)topic数据存储位置
1)启动生产者,并发送消息。
[zrclass@hadoop102 kafka]$ bin/kafka-console-producer.sh --bootstrap-server hadoop102:9092 --topic first
\>hello world
2)查看 hadoop102(或者 hadoop103、hadoop104)的/opt/module/kafka/datas/first-1 (first-0、first-2)路径上的文件。
[zrclass@hadoop104 first-1]$ ls
00000000000000000092.index
00000000000000000092.log
00000000000000000092.snapshot
00000000000000000092.timeindex
leader-epoch-checkpoint
partition.metadata
3)直接查看 log 日志,发现是乱码。
[zrclass@hadoop104 first-1]$ cat 00000000000000000092.log
CYnF|©|©ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ"hello world
4)通过工具查看 index 和 log 信息。
[zrclass@hadoop104 first-1]$ kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.index
Dumping ./00000000000000000000.index
offset: 3 position: 152
[zrclass@hadoop104 first-1]$ kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.log
Dumping datas/first-0/00000000000000000000.log
Starting offset: 0
baseOffset: 0 lastOffset: 1 count: 2 baseSequence: -1 lastSequence: -1 producerId: -1
producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 0 CreateTime: 1636338440962 size: 75 magic: 2 compresscodec: none crc: 2745337109 isvalid: true
baseOffset: 2 lastOffset: 2 count: 1 baseSequence: -1 lastSequence: -1 producerId: -1
producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 75 CreateTime: 1636351749089 size: 77 magic: 2 compresscodec: none crc: 273943004 isvalid: true
baseOffset: 3 lastOffset: 3 count: 1 baseSequence: -1 lastSequence: -1 producerId: -1
producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 152 CreateTime: 1636351749119 size: 77 magic: 2 compresscodec: none crc: 106207379 isvalid: true
baseOffset: 4 lastOffset: 8 count: 5 baseSequence: -1 lastSequence: -1 producerId: -1
producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 229 CreateTime: 1636353061435 size: 141 magic: 2 compresscodec: none crc: 157376877 isvalid: true
baseOffset: 9 lastOffset: 13 count: 5 baseSequence: -1 lastSequence: -1 producerId: -1
producerEpoch: -1 partitionLeaderEpoch: 0 isTransactional: false isControl: false position: 370 CreateTime: 1636353204051 size: 146 magic: 2 compresscodec: none crc: 4058582827 isvalid: true