kafka介绍

一、KafKa介绍

1、创建背景

Kafka是由LinkedIn开发的一个分布式的消息系统，使用Scala编写，主要设计目标如下：

①  以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。

②  高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上  消息的传输。

③  支持KafkaServer间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输

④  同时支持离线数据处理和实时数据处理。

⑤  Scale out：支持在线水平扩展。

 

2、术语

Broker

Kafka集群包含一个或多个服务器，这种服务器被称为broker

Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。

（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上，但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

Partition

每个Topic包含一个或多个Partition.

Producer

负责发布消息到Kafka broker

Consumer

消息消费者，向Kafka broker读取消息的客户端。

Consumer Group

每个Consumer属于一个特定的Consumer Group

Zookeeper

管理集群配置，

 

 

 

二、Kafka架构

1、kafka消息结构

图1、Kafka消息结构

         每一个topic包含多个partition，partition对应一个文件夹，文件夹下存储这个Partition的所有消息和索引文件。

发布者发到broker某个topic的消息会被均匀的分布到多个partition上（随机或根据用户指定的回调函数进行分布），broker收到发布消息往对应partition的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。

 

 

2、kafka拓扑结构

图2、Kafka拓扑结构

    

 

一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干broker（一般broker数量越多，集群吞吐率越高），若干Consumer Group，以及一个Zookeeper集群。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。Zookeeper用于管理集群配置。

 

三、Kafka消息处理机制

1、消息路由

Producer发送消息到broker时，会根据Paritition机制选择将其存储到哪一个Partition，如果Partition机制设置合理，所有消息可以均匀分布到不同的Partition里，这样就实现了负载均衡。（一个topic可以分布在不同的broker上，不同的消息可以并行写入不同broker的不同Partition里，极大的提高了吞吐率。）

2、消息接收

  每个Consumer属于一个特定的Consumer Group，同一Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。利用这种机制，可以实现广播，只要确保每个Consumer有一个独立的Group。另外，要实现单播只要所有的Consumer在同一个Group里。

  根据这一特性，可以使用Storm这种实时流处理系统对消息进行实时在线处理，同时使用Hadoop这种批处理系统进行离线处理，还可以同时将数据实时备份到另一个数据中心，只需要保证这三个操作所使用的Consumer属于不同的Consumer Group即可，即同时提供离线处理和实时处理。

2、   安全机制

Kafka在运行过程中，一旦一个或多个Broker宕机，则宕机期间其上所有Partition都无法继续提供服务。若该Broker永远不能再恢复，亦或磁盘故障，则其上数据将丢失。因此引入了Data Replication和LeaderElection两种机制来防止Broker宕机。

引入Replication之后，同一个Partition可能会有多个Replica。会在这些Replication之间选出一个Leader，Producer和Consumer只与这个Leader交互，其它Replica作为Follower从Leader中复制数据（但要确保所有的Partition以及其Replica均匀分配到整个集群上），一旦一个Broker宕机（Leader在其中），数据由于在多个follower上都有保存，在这些follower中找出新的Leader（但新的Leader必须拥有原来的Leader所获取到的所有消息）。

 

 

参考文章：http://www.infoq.com/cn/articles/kafka-analysis-part-2

                   http://blog.csdn.net/kimmking/article/details/8263057