Kafka原理

2019-08-20  本文已影响0人  一只小星_

一、producer设计原理

发消息的流程

1.计算分区
根本key和value的配置对消息进行序列化,如果指定了分区,就发送到指定的分区,如果没有指定,就用key%topic的分区数目,如果key也没有,就随机生成一个counter,用counter%topic的分区数目,这个counter每次使用完之后递增。
2.发送到batch,唤醒sender线程
根据分区获取到对应的batchs,然后将消息append到batch中,如果有batch满了就唤醒sender线程。队列的操作是加锁执行,所有batch内消息是有序的,后续的sender操作当前方法异步操作。(这应该就是分区可以有序的原因吧)
3.Sender把消息有序发到broker
3.1确定要发送分区的leader所在的broker
Kafka中每台都保存了kafka集群的元数据信息,metadata信息包括了每个topic所有的分区的信息:leader,leader-epoch,controller-epoch,isr,replicas等。Kafka客户端从任一broker都可以获取到需要的metadata。sender线程通过metadata信息知道要分送到的 leader的brokerId,producer也保存了metada信息,同时根据metadata更新策略:定期更新metadata.max.age.ms,失效检测,强制更新:检查到metadata失效以后,调用metadata.requestUpdate()强制更新。
3.2幂等性发送
为实现Producer的幂等,Kafka引入了Producer ID(PID)和Sequence Number,对于每个PID,该Producer发送的每一个<Topic,分区>都对应一个单调递增的Sequence Number,同样,Broker那里也会为每个<PID,Topic,分区>维护一个编号,每次发一个消息都将其对应序号递增。对于接收的每条消息,如果序号比Broker维护的序号大1,则Broker会接受它,否则丢掉。如果消息比broker维护的大,说明中间有数据没有写入,则是乱序,肯定不要。
**4.sender处理broker发来的producer response
一旦broker处理完Sender的produce请求,就会发送produce response给Sender,此时producer将执行我们send()设置的回调函数。至此producer的send完毕。

吞吐性&&延时

没想过。

Sender线程和长连接

每初始化一个producer实例,都会初始化一个Sender实例,新增到broker长连接,代码角度:每初始化一次KafkaProducer,都赋一个空的client。

二、Consumer设计原理

记得kafka消费每个分区是单线程消费的。

三、Kafka Group状态

四、重平衡reblance

当一些原因导致consumer对分区消费不再均匀时,kafka会自动执行reblance,使得consumer对分区的消费再次平衡,什么时候发生reblance?

五、Broker设计原理

broker zk注册
1.Broker注册
broker是分布式部署并且相互之间独立,但是需要有一个注册系统把整个集群中的broker管理起来,此时就用到了zk。zk上有一个专门用来进行broker服务器列表的节点:/brokers/ids
每个broker在启动的时候,都会到zk上注册,就是到/brokers/ids下创建属于自己的节点,如/brokers/ids/[0...N]
Kafka使用了全局唯一的数字来指代每个Broker服务器,不同的Broker必须使用不同的 broker id进行注册,创建完每个节点后,每个broker会把自己的ip和端口信息记录到节点中去。其中,broker创建的节点类型是临时节点,一旦broker宕机,对应的临时节点也会被自动删除。
2.Topic注册
在kafka中,同一个topic的消息会被分成分区存在多个broker上,这些分区信息及broker

broker消息存储
Kafka的消息以二进制的方式紧凑的存储,节省了很大空间 此外消息存在ByteBuffer而不是堆,这样broker进程挂掉时,数据不会丢,同时避免了GC,通过零拷贝和顺序寻址,让消息存储和读取速度都非常快,处理fetch请求的时候通过zero-copy加快速度。
broker状态数据

上一篇下一篇

猜你喜欢

热点阅读