kafka基础知识

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 Kafka的目的是通过hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。

Kafka 主要特点：

· 同时为发布和订阅提供高吞吐量。据了解，Kafka 每秒可以生产约 25 万消息（50 MB），每秒处理55万消息（110 MB）。

· 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。

· 分布式系统，易于向外扩展。所有的 producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。

· 消息被处理的状态是在 consumer 端维护，而不是由 server 端维护。当失败时能自动平衡。

· 支持 online 和offline的场景。

Kafka中最基本的数据单元是消息message，如果使用过数据库，那么可以把Kafka中的消息理解成数据库里的一条行或者一条记录。消息是由字符数组组成的，kafka并不关系它内部是什么，索引消息的具体格式与Kafka无关。消息可以有一个可选的key，这个key也是个字符数组，与消息一样，对于kafka也是透明的。key用来确定消息写入分区时，进入哪一个分区。最简单的处理方式，就是把key作为hash串，拥有相同key的消息，肯定会进入同一个分区。

Kafka以批量的方式写入。一个batch就是一组消息的集合，这一组的数据都会进入同一个topic和partition（这个是根据producer的配置来定的）。batch越大，同一时间需要被处理的消息就越多，通常都会进行压缩batch，这样在传输以及存储的时候效率都更高一些。

 

Kafka中数据是连续的，在数据在写入到同时也可能被读取消费。

 

消息都是以主题Topic的方式组织在一起，Topic也可以理解成传统数据库里的表，或者文件系统里的一个目录。一个主题由broker上的一个或者多个Partition分区组成。在Kafka中数据是以Log的方式存储，一个partition就是一个单独的Log。消息通过追加的方式写入日志文件，读取的时候则是从头开始按照顺序读取。注意，一个主题通常都是由多个分区组成的，每个分区内部保证消息的顺序行，分区之间是不保证顺序的。

 

消费者订阅一个或者多个主题，然后按照顺序读取主题中的数据。消费者需要记录已经读取到消息的位置，这个位置也被叫做offset。每个消息在给定的分区中只有唯一固定的offset。通过存储最后消费的Offset，消费者应用在重启或者停止之后，还可以继续从之前的位置读取。保存的机制可以是zookeeper,或者kafka自己。消费者是以consumer group消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个topic。每个分区在同一时间只能由group中的一个消费者读取，。

 

单独的kafka服务器也叫做broker，Broker从生产者那里获取消息，分配offset，然后提交存储到磁盘。他也会提供消费者，让消费者读取分区上的消息，并把存储的消息传给消费者。依赖于一些精简资源，单独的broker也可以轻松的支持每秒数千个分区和百万级的消息。

 

Kafka的broker支持集群模式，在Broker组成的集群中，有一个节点也被叫做控制器（是在活跃的节点中自动选择的）。这个controller控制器负责管理整个集群的操作，包括分区的分配、失败节点的检测等。一个partition只能出现在一个broker节点上，并且这个Broker也被叫做分区的leader。一个分区可以分配多个Broker，这样可以做到多个机器之间备份的效果。这种多机备份在其中一个broker失败的时候，可以自动选举出其他的broker提供服务。然而，producer和consumer都必须连接leader才能正常工作。

 

Kafka的一个重要特性就是支持数据的过期删除，数据可以在Broker上保留一段时间。Kafka的broker支持针对topic设置保存的机制，可以按照大小配置也可以按照时间配置。一旦达到其中的一个限制，可能是时间过期也可能是大小超过配置的数值，那么这部分的数据都会被清除掉。每个topic都可以配置它自己的过期配置，因此消息可以按照业务的需要进行持久化保留。比如，一个数据追踪分析的topic可以保留几天时间，一些应用的指标信息则只需要保存几个小时。topic支持日志数据的压缩，这样kafka仅仅会保留最后一条日志生成的key。这在修改日志类型的时候会非常有用。

 

磁盘吞吐
Producer客户端生产消息的性能主要取决于broker磁盘写入的速度。Kafka的消息在产生的时候在本地存储，并且大多数的客户端都会一直等到broker确认写入成功后，才认为消息提交成功。

 

如果数据需要被多个应用程序消费的话，推荐使用 Kafka，如果数据只是面向 Hadoop 的，可以使用 Flume。