kafak组件详解

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