Kafka记录

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_26917447/article/details/79969382

强调内容kafka是一个发布-订阅式的消息队列系统。
啥是发布-订阅式?
就是一个负责发布消息,另一个订阅后负责处理发布的消息。
负责发布的叫producer生成者
负责订阅并处理的叫consumer消费者
发布的消息旧版叫message,在java里叫record,是一个固定长度的消息头和可变长度的消息体组成。
每个消息都有一个主题”topic”
1.producer生产了消息要发送给服务器或是kafka集群(多台服务器)
一个kafka实例称为代理broker,也就是kafka服务器,拥有唯一的标志id,也就是启动代理配位的broker.id
2.发送的消息存储在服务器中的日志队列,
【日志有不同分区,每个分区都由一系列有序不可变的消息组成,每个消息拥有唯一的标志offset序列号(该消息在队列中的位置)】
3.然后服务器转发给consumer
5.然后consumer消费收到的消息

-每个consumer都有全局唯一的id,通过client.id配置;
-consumer可以被分为不同组,以group.id为组名,每组至少一个consumer
-同一个topic的一条消息只能被consumer组内的某一个consumer消费。但可以被不同的组同时消费
-consumer消费消息其实就是对消息的offset的修改

6.每个分区都是一个顺序的,不可变的消息队列并且可以持续的增加。分区中的消息都被分配了一个序列号称之为偏移量,在每个分区中该偏移量是唯一的。kafka集群保存所有的消息直到它们过期,无论是否被消费。每个消息的偏移量都可以被消费者控制更改。
7.分布式
分区被分布到集群中的多个服务器上,每个服务器处理它分到的分区。根据配置每个分区还可以复制到其他服务器作为备份容错。每个分区有一个leader,有0个或多个follower。Leader处理此分区的所有的读写请求而follower被动复制数据。
如果leader宕机其他的一个Follower会被推举为新的leader.一台服务器可能同时是一个分区的leader却是另一个分区的Follower。这样可以平衡负载避免所有的请求都只让一台或某几台服务器处理。

ps: 如果一个topic配置 了复制因子(replication Factor)为N,那么可以允许N-1台服务器宕机而不丢失任何已经增加的消息。
8. Broker与Leader的选举
kafka Broker集群受zookeeper管理。所有的kafka broker节点同时去zk注册一个临时节点,因为只有一个kafka broker会注册成功,其他都会失败。所以这个成功注册临时节点的broker会成为kafka broker Controller , 其他的broker就叫follower。(这个过程叫controller在zookeeper注册watch)。这个controller会监听其他的broker所有信息,如果该controller宕机,在zk上的临时节点就会消失,此时所有的kafka broker节点又会一起去zk注册一个临时节点。
【一旦某个broker宕机了,这个broker controller会读取该宕机Broker所有的partiton在zookeeper上的状态,并选取ISR列表中的replica作为partition Leader(如果ISR列表中的replica都挂了,就选一个幸存的replica作为leader;如果所有replica都宕机,则新的leader设置为-1,等待恢复,等待ISR中的任一replica复活,并选它作为Leader,或选择第一个正常的replica(不一定是ISR)作为Leader)。broker宕机,kafka controller会通知zk,zk就会通知其他kafka broker.
kafka controller在Zookeeper上注册成功后,它和Zookeeper通信的timeout时间是6s,也就是如果kafka controller如果有6s中没有和Zookeeper做心跳,那么Zookeeper就认为这个kafka controller已经死了,就会在Zookeeper上把这个临时节点删掉,那么其他Kafka就会认为controller已经没了,就会再次抢着注册临时节点,注册成功的那个kafka broker成为controller,然后,之前的那个kafka controller就需要各种shut down去关闭各种节点和事件的监听。

阅读更多

没有更多推荐了,返回首页