一、简介
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
官网介绍ApacheKafka®是一个分布式流媒体平台。这到底是什么意思呢？流媒体平台有三个关键功能：
1.发布和订阅记录消息流，类似于消息队列或企业消息传递系统。
2.以容错的持久方式存储记录流。
3.在消息流发生时处理流。
也就是说Kafka能够允许发布和订阅流数据。从这个角度来讲，平台更像一个消息队列或者企业级的消息系统。存储流数据时提供相应的容错机制。当流数据到达时能够被及时处理。
二、基本术语与设计原理
2.1 Topic 主题
Kafka将一组组消息抽象归纳为一个主题（ Topic ），也就是说，一个主题就是对消息的一个分类。生产者将消息发送到特定主题，消费者订阅主题或主题的某些分区进行消费。
2.2 Partition&Offset 分区和偏移量
Kafka将一组消息归纳为一个主题（topic），而每个主题又被分成一个或多个分区（Partition），每个分区在物理上对应为一个文件夹，分区的命名规则为主题名称后接“一”连接符，之后再接分区编号，分区编号从0开始，编号最大值为分区的总数减1，每个分区又有1至多个副本（Replica），分区的副本分布在集群的不同代理上，以提高可用性。
每个分区由一系列有序、不可变的消息组成，是一个有序队列，并且可以持续的添加。分区中的消息都被分了一个序列号，称之为偏移量(offset)，在每个分区中此偏移量都是唯一的。任何发布到分区的消息会被直接追加到日志文件（分区目录下以＂ .log ”为文件名后缀的数据文件〉的尾部，而每条消息在日志文件中的位置都会对应一个按序递增的偏移量 。偏移量是每个分区下严格有序的逻辑值，它并不表示消息在磁盘上的物理位置，由于 Kafka 几乎不允许对消息进行随机读写，因此 Kafka 并没有提供额外索引机制到存储偏移 ，也就是说并不会给偏移量再提供索引。
消费者可以通过控制消息偏移量来对消息进行消费，如消费者可以指定
消费的起始偏移量。为了保证消息被顺序消费 消费者已消费的消息对应的偏移量也需要保存。需要说明的是，消费者对消息偏移量的操作并不会影响消息本身的偏移量。 旧版消费者将消费偏移量保存到 ZooKeeper 当中，而新版消费者是将消费偏移量保存到Kafka内部每个主题当中当然，消费者也可以自己在外部系统保存消费偏移 ，而无需保存到 Kafka
Kafka 只能保证一个分区之内消息的有序性，并不能保证跨分区消息的有序性。每条消息被追加到相应的分区中，是顺序写磁盘，因此效率非常高，这是 Kafka 高吞吐率的一个重要保证。
Kafka中采用分区的设计有几个目的。一是可以处理更多的消息，不受单台服务器的限制。Topic拥有多个分区意味着它可以不受限的处理更多的数据。第二，分区可以作为并行处理的单元，稍后会谈到这一点。
2.3 Producer 生产者
发布消息的对象称之为主题生产者(Kafka topic producer)。生产者负责将消息发送给代理，也就是向 Kafka 代理发送消息的客户端。生产者可以向一个或多个Kafka主题的发送消息。生产者还可以向他们选择的分区发送消息。
2.4 Consumer&Group 消费者和消费组
订阅消息并处理发布的消息的对象称之为主题消费者(consumers)。消费者可以订阅一个或多个主题，并以拉取（ pull ）的方式消费数据。
在Kafka中每一个消费者都属于一个特定消费组（ConsumerGroup），我们可以为每个消费者指定一个消费组，以groupld代表消费组名称，如果不指定消费组，则该消费者属于默认消费组test-consumer-group，同时，每个消费者也有一个全局唯一的id，通过配置项client.id指定，如果客户端没有指定消费者的id, Kafka会自动为该消费者生成一个全局唯一id，格式为$ {groupld }-$ {hostName }-$ {timestamp}-$ {UUID字符｝。
同一个主题的一条消息只能被同一个消费组下某一个消费者消费，但不同消费组的消费者可同时消费该消息，消费组是Kafka用来实现对主题消息进行广播和单播的手段，实现消息广播只需指定各消费者均属于不同的消费组，消息单播则只让各消费者属于同个消费组。
也就是说，Kafka消息模型可以分为两种， 队列和发布-订阅式。 队列的处理方式是：同一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。在发布-订阅模型中，消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。
2.5 Broker 代理
Kafka集群就是由一个或多个 Kafka例构成，我们将每一个Kafka实例称为代理（Broker），通常也称代理为 Kafka 服务器( KafkaServer）。在生产环境中Kafka集群一般包括一台或多台服务器，我们可以在一台服务器上配置一个或多个代理。每个代理都有唯一的标识id ，这个id是一个非负整数。
已发布的消息保存在一组服务器中，称之为Kafka集群。集群中的每一个服务器都是一个代理(Broker)。消费者可以订阅一个或多个主题（topic），并从Broker拉数据，从而消费这些已发布的消息。
2.6 Leader&Follower 领导者和追随者
由于Kafka副本的存在，就需要保证每个分区的多个副本之间数据的一致性，Kafka会选择该分区的一个副本作为Leader副本，而该分区其他副本即为 Follower副本，只有Leader才负责处理客户端读／写请求，Follower副本从 Leader副本同步数据，如果 Leader失效，通过相应的选举算法将从其他 Follower副本中选出新的Leader副本。
三、Kafka基本结构
通过前面对Kafka基本概念的介绍，我们对Kafka有了初步的了解，本节我们将进一步介绍Kafka作为消息系统的基本结构。
3.1 基本业务结构
如下图，主题配置为三个分区。分区1具有两个偏移因子0和1.分区2具有四个偏移因子0,1,2和3.分区3具有一个偏移因子0.副本的id与承载它的服务器的id相同。
假设，如果主题的复制因子设置为3，那么Kafka将创建每个分区的3个相同的副本，并将它们放在集群中以使其可用于其所有操作。 为了平衡集群中的负载，每个代理都存储一个或多个这些分区。 多个生产者和消费者可以同时发布和检索消息。
3.2 程序组件结构
Kafka程序有四个核心的API:
The Producer API 允许一个应用程序发布一串流式的数据到一个或者多个Kafka topic。
The Consumer API 允许一个应用程序订阅一个或多个 topic ，并且对发布给他们的流式数据进行处理。
The Streams API 允许一个应用程序作为一个流处理器，消费一个或者多个topic产生的输入流，然后生产一个输出流到一个或多个topic中去，在输入输出流中进行有效的转换。
The Connector API 允许构建并运行可重用的生产者或者消费者，将Kafka topics连接到已存在的应用程序或者数据系统。比如，连接到一个关系型数据库，捕捉表（table）的所有变更内容。
四、使用场景
4.1消息系统
Kafka 作为一款优秀的消息系统，具有高吞吐量、内置的分区、备份冗余、分布式等特点，为大规模消息处理提供了一种很好的解决方案。
4.2应用监控
利用 Kafka 采集应用程序和服务器健康相关的指标，如 CPU 占用率、 IO、内存、连接数、TPS、QPS 等，然后将指标信息进行处理，从而构建一个具有监控仪表盘、曲线图等可视化监控系统。例如，很多公司采用Kafka ELK (Elastic Search Logstash Kibana)整合构建应用服务监控系统。
4.3网站用户行为追踪
为了更好地了解用户行为、操作习惯，改善用户体验，进而对产品升级改进，将用户操作轨迹、内容等信息发送到Kafka集群上，通过Hadoop、Spark 、Strom等进行数据分析处理，生成相应的统计报告，为推荐系统推荐对象建模提供数据源，进而为每个用户进行个性化推荐。
4.4流处理
需要将己收集的流数据提供给其他流式计算框架进行处理，用Kafka收集流数据是一个不错的选择，而且当前版本的Kafka提供了Kafka Streams支持对流数据的处理。
4.5持久性日志
Kafka 可以为外部系统提供一种持久性日志的分布式系统。日志可以在多个节点间进行备份，Kafka为故障节点数据恢复提供了一种重新同步的机制。同时，Kafka很方便与HDFS、Flume进行整合，这样就方便将Kafka采集的数据持久化到其他外部系统。
