kafka组件介绍:
- Topic :消息根据Topic进行归类
- broker:每个kafka实例(server) ,相当于一个节点
- zookeeper:分布式服务框架在kafka 中的作用主要负责保存topic ,partition 元数据,和对broker 的监控及治理,以及partition 的leader 选举
- partition:分区,topic 中的消息都是存放在patition 中,一个topic 可以有多个partition,一个partition 可以有多个副本
- Producer:发送消息者
- Consumer:消息接受者
- 数据写入的时候是顺序写入
注意:partition 可以有多个副本,但是只有一个处于工作状态,副本只是负责同步数据,当leader partition 死掉了,会把起作一个副本的partition 升级为leader
kafka的架构
kafka目录介绍:
-
recovery-point-offset-checkpoint文件,记录了当前log目录下各个TopicPartition可用于恢复的offset信息,从这个offset开始后面的message都还木有flush到disk。
-
meta.properties文件,记录了版本号和当前Server实例的broker id,这个broker id会跟zookeeper上的信息进行关联,而且在后续的竞选Controller和各种协作中发挥作用。此文件中的broker id必须要跟配置文件里面的broker id一样,如果log.dirs指定了多个目录,则每个目录下这个文件的broker id必须一样,否则就会启动出错。如果配置文件没有指定broker id但允许自动生成,则会从zookeeper上通过sequenceNumber来生成它
-
log-start-offset-checkpoint文件,日志可以返回给Client的最开始边界,对应earliest offset,最初始的值为0,如果日志被定期删除,则会被update成大于0的值。
-
cleaner-offset-checkpoint,每次清理完,要更新当前已经清理到的位置, 记录在文件中,作为下一次清理时生成firstDirtyOffset的参考
-
.kafka_cleanshutdown文件,标志Server的退出是正常的,下一次启动的时候会检查是否存在它,如果存在的话,就可以跳过一些恢复的环节。但是如果有些LogSegment在自检查的时候发现有错,还是会进入对应的恢复过程的。
-
replication-offset-checkpoint, 负责记录已经被复制到别的topic上的文件
-
__consumer_offsets,存储各个topic的offset。但是,他的只有一份
-
topic文件夹,数据的存放位置
包括:log,index,timeindex文件组成一个segment,每次打到1g进行切片
log存储的是真正的数据,index存储的是每条数据的偏移量,index一样
kafka的消费者
- 将zookeeper维护offset 的方式称为 high level API,查看可以在zookeeper的consumer上
- 将kafka broker 维护offset的方式称为low level API
- 自动提交,设置enable.auto.commit=true,更新的频率根据参数【auto.commit.interval.ms】来定。这种方式也被称为【at most once】,fetch到消息后就可以更新offset,无论是否消费成功。
- 手动提交,设置enable.auto.commit=false,这种方式称为【at least once】。fetch到消息后,等消费完成再调用方法【consumer.commitSync()】,手动更新offset;如果消费失败,则offset也不会更新,此条消息会被重复消费一次。
- 消费组包括多个消费者,一个消费者对应一个partition。就是一个线程对应一个partition