Kafka学习之路(二)Kafka的架构

Kafka学习之路(二)Kafka的架构

一丶Kafka的架构

如上图所示,一个典型的Kafka集群中包含若干Producer(可以是wen前端产生的Page View,或者是服务器日志,系统CPU,Memory等),若干broler(Kafka支持水平扩展,一般broker数量越多,集群吞吐率越高),若干ConsumerGroup,以及一个Zookeeper集群,Kafka通过Zookeeper管理集群配置,选举leader,以及在Consumer Group 发生变化时进行rebalance.Producer使用push模式将消息发布到roker,Consumer使用pull模式从broker订阅并消费消息.

二丶Topics和Partition
Topic在逻辑上可以比认为是一个queue,每条消息都必须指定它的Topic,可以简单理解必须指明吧这条消息放进那个queue里,为了使得Kafka的吞吐率可以线性提高,物理上把Topic分成一个或多个Partition,每个Partition在物理上对应一个文件夹,该文件夹下存储这个Partition的所有消费和索引文件,创建一个topic时,同时可以指定分区数目,分区数越多,其吞吐量越大,但是需要的资源也越多,同时也会导致跟高的不接可用性,kafka在接受到生产者发送的消息之后,会根据均衡策略将消息存储到不同的分区中,因为每条消息都被append到该Partition中,属于顺序写磁盘,因此效率非常高(经验证,顺序写磁盘效率比随机写内存还要高,这是kafka高吞吐率的一个很重要的保证).

对于传统的message queue而言,一般会删除已经被消费的消息,而kafka集群会保留所有的消息,无论其被消费与否,当然,因为磁盘限制,不可能永久保留所有数数据(实际上也没有必要),因此kafka提供两种策略删除旧数据,一是基于时间,而是基于Partition文件大小,列如可以通过配置$KAFKA_HOME/config/server.properties.让kafka删除一周前的数据,也可以在partition文件超过1GB时删除旧数据,配置如下所示:

# The minimum age of a log file to be eligible for deletion
log.retention.hours=168
# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=1073741824
# The interval at which log segments are checked to see if they can be deleted according to the retention policies
log.retention.check.interval.ms=300000
# If log.cleaner.enable=true is set the cleaner will be enabled and individual logs can then be marked for log compaction.
log.cleaner.enable=false

因为kafka读取特定消息的时间复杂程度O(1),即与文件大小无关,所以这里删除过期文件与提高kafka性能无关,选择怎样的删除策略只与磁盘以及具体的需求有关,另外,kafka会为每一个ConsumerGroup保留一些metadata信息----当前消费的消息的position,也即offset,这个offset由Consumer控制,正常情况下Consumer会在消费完一条消息后递增该offset,当然,Consumer也可将offset,当然,coonsumer也可将offset设置成一个较小的值,也不需要通过broker去保证同一个Consumer Group只有一个Consumer能消费某一条消息,因此就不需要锁机制,这也为Kafka的高吞吐率提供了有力保障

三丶Producer消息路由

Producer发送消息到broker时,会根据Partition机制选择将其存储到哪一个Partition,如果Partition机制设置合理,所有消息可以均匀分布到不同的Partition里,不同的消息可以并行写入不同broker的不同Parition里,极大的提高看吞吐率,可以$KAFKA_HOME/config/server.properties中通过配置项num.partitions来指定新建Topic的默认Partition数量,也可在创建Topic是通过参数指数,同时也可以在topic创建之后通过kafka提供的工具修改,在发送一条消息时,可以指定这条消息的key,Producer根据这个key和Partition机制来判断应该将这条消息发送到那个Partition.Partition机制可以通过指定Producer的partition.calss这以参数来指定,该class必须实现kafka.produce.Partitioner接口

四丶Consumer Group

使用Consumer high level AP时.同一Topic的一条消息只能被同一个Consumer
Group内的一个Consumer消费,但说个Consumer Group 可同时消费这一消息,

这是Kafka用来实现一个Topice消息的广播,(发给所有的Consumer)和单个(发给一个Consumer)的手段,一个Topic可以对应多个Consumer
Group
如果需要实现广播,只要每个Consumer有一个独立的Group就可以了,要实现单播只要所有的Consumer在同一个Group里,用Consumer
Group还可以将consumer进行自由的分组而不需要多次发送消息到不同的Topic.实际上,Kafka的设计理念之一就是同事提供龙里县处理和实时处理,根据这一特性,可以使用Storm这种实时流处理系统对消息进行实时在线处理,同事使用Hadoop这种批处理系统进行离线处理,还可以同时将数据实时备份到宁一个数据中心,只需要保证这三个操作所使用的Consumer属于不同的Consumer
Group即可

五丶Push vs.Pull

作为一个消息系统,Kafka遵循了传统的方式,选择有Producer向broker push消息并由Consumer从broker
pull消息,一些logging-centric system
,比如Facebiik的Scribe和Clouder的Flume,采用push模式,事实上,push模式和pull模式各有优劣,
push模式很难适应消费速率不同的消费者,因为消息发送速率是由broker决定的,push模式的目标是尽可能最快速度传递消息,但是这样很容易造成Consumer来不及处理消息,典型的变现就是拒绝服务以及网络拥塞,而pull模式则可以根据Consume的消费能力以适当的速率消费消息,对于Kafka而言,pull模式更合适,pull模式可简化broker的设计,Consumer可自主控制消费小子的速率,同时Consumer可以自己控制消费方式-------即可批量消费也可逐条消费,同时还能选择不同的提交方式从而实现不同的传输语义.

六丶Kafka delivery guarantee

有这么几种可能的delivery guarantee:

At most once 消息可能会丢失,但绝不会重复传输
At least one 消息绝不会丢失,但可能会重复传输 Exactly
once 每条消息肯定会被传输一次,很多时候这是用户所想要的

当Produce向broker发送消息时,一旦这条消息被commit,因数replication,它就不会丢失,但是如果Producer发送数据给broker后,遇到网络问题而赵成通信中断,那Producer就无法判断该消息是否已经commit,虽然Kafka无法确定网络故障期间发生了审美,但是Producer可以生成一种类似于主键的东西,发生故障时幂等性的重试多次,这样就做到了Exactly once.
接下来讨论的是消息从broker到Consumer的delivery guarantee语义,(仅针对Kafka consumer high level API) consumer在从broker读取消息后,可以选择commit,该操作会在Zookeeper中保存该Consumer在该Partition中读取的消息的offset,该Consumer下一次再读该Partition时会从下一条开始读取的开始位置会跟上一次commmit之后的开始位置相同,当然可以将Consumer设置为autocommit,即Consumer,下次读取的开始位置会个跟上一次commit之后的开始位置相同,当然可以将Consumer设置为autocommit,即Consumer一旦读取到数据立即自动commit,如果只讨论这一读取消息的过程,那kafka的确保了Exactly once 但实际使用中应用程序并非在Consumer读取完数据就结束了,而是进行进一步处理,而数据处理与commit的顺序在很大程度上决定看消息从broker和xonsumer的delivery guarantee semantic
Kafka默认保证At least once,并且允许通过设置Producer异步提交来实现At most once,而Exactly once 要求与外部存储协作,幸运的是Kafka提供的offset可以非常直接非常容易的使用这种方式