kafka系统设计开篇
以下文章来源于靳刚同学 ,作者靳刚同学
戳蓝字“CSDN云计算”关注我们哦!
来源 | 靳刚同学
能够发布和订阅消息流(类似于消息队列)
以容错的、持久的方式存储消息流
多分区概念,提高了并行能力
Topic
Partition
Broker
Producer
Cousumer
CousumerGroup
Kafka中 每台broker都保存了kafka集群的metadata信息,metadata信息里包括了每个topic的所有partition的信息: leader, leader_epoch, controller_epoch, isr, replicas等;Kafka客户端从任一broker都可以获取到需要的metadata信息;sender线程通过metadata信息可以知道tp leader的brokerId
producer也保存了metada信息,同时根据metadata更新策略(定期更新metadata.max.age.ms、失效检测,强制更新:检查到metadata失效以后,调用metadata.requestUpdate()强制更新
public class PartitionInfo {
private final String topic;
private final int partition;
private final Node leader;
private final Node[] replicas;
private final Node[] inSyncReplicas;
private final Node[] offlineReplicas;
}
buffer.memory:buffer设置大了有助于提升吞吐性,但是batch太大会增大延迟,可搭配linger_ms参数使用
linger_ms:如果batch太大,或者producer qps不高,batch添加的会很慢,我们可以强制在linger_ms时间后发送batch数据
ack:producer收到多少broker的答复才算真的发送成功
0表示producer无需等待leader的确认(吞吐最高、数据可靠性最差)
1代表需要leader确认写入它的本地log并立即确认
-1/all 代表所有的ISR都完成后确认(吞吐最低、数据可靠性最高)
public KafkaProducer(final Map<String, Object> configs) {
this(configs, null, null, null, null, null, Time.SYSTEM);
}
消费者通过fetch线程拉消息(单线程)
消费者通过心跳线程来与broker发送心跳。超时会认为挂掉
每个consumer group在broker上都有一个coordnator来管理,消费者加入和退出,以及消费消息的位移都由coordnator处理。
Empty:初始状态,Group 没有任何成员,如果所有的 offsets 都过期的话就会变成 Dead
PreparingRebalance:Group 正在准备进行 Rebalance
AwaitingSync:Group 正在等待来 group leader 的 分配方案
Stable:稳定的状态(Group is stable);
Dead:Group 内已经没有成员,并且它的 Metadata 已经被移除
注意
组订阅topic数变更
topic partition数变更
consumer成员变更
consumer 加入群组或者离开群组的时候
consumer被检测为崩溃的时候
使用join协议,表示有consumer 要加入到group中
使用sync 协议,根据分配规则进行分配
Kafka的消息以二进制的方式紧凑地存储,节省了很大空间
此外消息存在ByteBuffer而不是堆,这样broker进程挂掉时,数据不会丢失,同时避免了gc问题
通过零拷贝和顺序寻址,让消息存储和读取速度都非常快
处理fetch请求的时候通过zero-copy 加快速度
controller所在的broker ID,即保存了当前集群中controller是哪台broker
集群中所有broker的信息:比如每台broker的ID、机架信息以及配置的若干组连接信息
集群中所有节点的信息:严格来说,它和上一个有些重复,不过此项是按照broker ID和监听器类型进行分组的。对于超大集群来说,使用这一项缓存可以快速地定位和查找给定节点信息,而无需遍历上一项中的内容,算是一个优化吧
集群中所有分区的信息:所谓分区信息指的是分区的leader、ISR和AR信息以及当前处于offline状态的副本集合。这部分数据按照topic-partitionID进行分组,可以快速地查找到每个分区的当前状态。(注:AR表示assigned replicas,即创建topic时为该分区分配的副本集合)
将所有Broker(假设共n个Broker)和待分配的Partition排序
将第i个Partition分配到第(i mod n)个Broker上
将第i个Partition的第j个Replica分配到第((i + j) mod n)个Broker上
新版本改进
同步复制:要求所有能工作的Follower都复制完,这条消息才会被认为commit,这种复制方式极大的影响了吞吐率
异步复制:Follower异步的从Leader pull数据,data只要被Leader写入log认为已经commit,这种情况下如果Follower落后于Leader的比较多,如果Leader突然宕机,会丢失数据
首先kafka保证了对已提交消息的at least保证
Sender有重试机制
producer业务方在使用producer发送消息时,注册回调函数。在onError方法中重发消息
consumer 拉取到消息后,处理完毕再commit,保证commit的消息一定被处理完毕
consumer拉取到消息先保存,commit成功后删除缓存数据
partition提升了并发
zero-copy
顺序写入
消息聚集batch
页缓存
增大producer数量
ack配置
batch
福利
扫描添加小编微信,备注“姓名+公司职位”,加入【云计算学习交流群】,和志同道合的朋友们共同打卡学习!
推荐阅读: