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 副本同步时,延迟过多的副本。