kafka官方文档-简介

1.1 简介

Apache kafka 是一个流数据平台。

我们认为一个流式数据处理平台有以下三个方面的能力：

1.它可以发布或订阅流数据，类似于消息队列或者企业消息系统。

2.它可以容错存储记录的数据流。

3.它可以实时的处理记录的数据流。

kafka用途

1.在系统或者应用程序之间构建实时数据传输管道。

2.构建实时处理数据流的应有程序。

基本概念

1.kafka是以集群部署方式运行在一台或多台服务器上。

2.kafka存储数据的类别成为topic

3.在kafka中每一条记录包含一个key，一个value以及一个时间戳

核心APIs

Producer API：也叫做生产者API，应用程序通过这些API可以发布记录的数据流到一个或多个topic上。

Consumer API：消费者API，应用程序可以通过消费者API订阅一个或多个topic上的记录，并对这些记录进行处理。

Streams API：通过调用Streams API，应用程序可以对一个或多个Topic上的记录进行转换处理，同时将处理后的记录发布到一个或多个Topic上。

Connector API：通过Connector API可以构建和运行可重用的生产者和消费者，能够把topic连接到现有的应用程序或数据库。比如，一个数据库连接器可以捕获每个表的变化。

kafka客户端与服务端的通信是基于一个简单的、高性能的、语言无关的TCP协议。这个协议是向下兼容的。我们提供了一个java语言的客户端，并且还有很多语言版本的客户端。

Topics 和 Logs

首先研究一下kafka提供的一个核心概念-topic。

topic是发布的记录的类别或者摘要的名称，在kafka中topic可以被0个，1个，或多个消费者订阅。

每一个Topic，kafka集群都维护一个分段（partition）日志，如下图：

每个分区都是一个有序的、不可变的记录序列，以提交日志的方式不断的被追加。分区中的记录都分配了一个名为顺序id号-偏移量，它惟一地标识分区中的每个记录。

kafka集群保存所有被发布的记录，不管这些记录是否被消费，通过配置可以设置保存期。比如，如果将保留策略设置为两天，在记录发布后两天，它可被消费，之后它将被丢弃以腾出空间。Kafka的性能跟存储的数据量的大小无关， 所以将数据存储很长一段时间是没有问题的

事实上，保留在每个消费者元数据中的基础数据就是消费者正在处理的当前记录的偏移量或位置。这个偏移量是由消费者控制的，通常情况下，消费者随着读取记录线性的增加偏移量，但是，事实上，因为消费记录的位置是由消费者控制的，消费者可以按照它喜欢的方式消费记录。比如，消费者可以

设置旧的偏移量处理以前的记录，也可以跳过很多最近的记录从当前开始消费记录。

以上这些特性决定了kafka的消费者是非常轻量的，它对整个集群或者其他消费者的几乎没有影响，比如：你可以使用命令行工具tail任何topic中的内容，而不影响其他的已经存在的消费者。

采用日志分区主要是出于以下的目的：第一，分区运行日志文件超出服务器对单个文件大小的限制。每一个分区必须遵守服务器文件大小的限制，但是一个topic可以有多个分区，因此可以处理大量数据。第二，分区可以作为并行单位运行。

分布式（distribution）

Partition分布在kafka集群的服务器上，每个分区配置一定数量的副本在集群服务器上提供容错能力，每个服务器会共享分区进行数据请求的处理。

每个分区都有一个对应的“leader”服务器，同时具有0个或多个“followers”服务器。leader服务器处理分区上的所有读写请求，follower服务器被动的复制leader服务器上的数据。如贵leader失败了，其中一个follower将自动变成leader。每个服务器都会从当分布在其上的分区的某些分区的领导则，而其他分区会在follower服务器上均匀分布。

生产者（producers）

生产者将数据发布到他选择的topic中，生产者负责指定将数据发送到topic中的那个partition上。可以通过简单的循环方式来实现负载均衡，也可以通过一些复杂的语义算法来实现（例如：根据记录中的一些Key）。

消费者（consumers）

每个消费者都隶属于某个消费群，每个发布到topic的记录都会被发送给一个订阅消费者组中的一个消费者实例上。消费则实例可以是一个单独的进程也可以是单独的一台机器。

如果所有的消费者实例都属于同一个消费者组，那么记录将被均匀的发送给消费者实例。

如果消费者实例在不同的消费群中，那么记录将被广播给所有的消费者进程。

如上图，两台服务器的kafka集群上分布四个partition（P0-P3），两个消费群，消费群A有两个消费者实例，消费群B有四个

通常，我们会发现Topic有少量的消费群，每个消费群都是“逻辑上的订阅者”。每没消费群都是由很多消费者实例组成，从而实现可扩展性和容错性。这是Pub/Sub模式的再现，区别是这里的订阅者是一组消费者而不是一个单一的进程的消费者。

kafka实现消费群的方式是将分区分配给每个消费者实例，每个实例在任何时间点都能够公平分享独占的分区。维持消费群中的成员关系是通过kafka的动态协议处理的。如果有新的实例加入消费群中，它会接管该群中其他成员的一部分分区，如果一个实例挂掉，它管理的分区将被分配给其他的实例。

kafka只能保证一个分区内的记录有序，不能保证topic中不同的分区之间的记录也是有序的。对于多数应用程序来说，记录的排序和根据key进行数据分区的能力是足够的。但是，如果要让所有的记录都是有序的，可以通过只有一个分区的topic来实现，这意味着每个消费群同时只能有一个消费进程在消费。

保证

kafka提供以下高级别的保证：

一个生产者发送给一个topic的partition的消息将按发送顺序进行追加。也就是说，当一个生产者同时产生了M1和M2两个消息，M1先发送，那么M1在分区中的偏移量一定比M2小，在日志中出现的更早。

消费者按顺序处理存储在日志中的消息记录。

对于副本因子N的Topic，将承受最多N-1次服务器故障切换而不会损失任何的记录。

更多保证内容参见设计文档

kafka作为消息系统

相比传统的企业消息系统，kafka的设计理念是什么样的呢？

传统的消息系统有两个模式：队列和发布/订阅。队列模式，一个消费者池可以从服务器上读取数据，请求每个记录数据只会分配给其中一个消费者。发布/订阅模式，记录数据会广播给所有的消费者。这两种模式都有各种的优缺点，队列模式的优点是它可以将要的处理数据拆分，并发送到多个消费者上进行处理，这让你可以对处理进行扩展，但是队列模式不是多播的，一旦一个消费者进程读取了数据，这条数据在队列中就消失了。发布/订阅模式可以将数据广播到多个进程上，但是由于每个消息都会被所有的订阅者接收，因此无法进行扩展处理。

kafka的消费者群的概念包含了上面两个概念，队列模式，可以将要处理的数据分配给消费群上不同的消费者实例处理。作为发布订阅模式，kafka运行将消息广播到到多个消费群上。

kafka的topic兼具队列模式和发布/订阅模式-既可以进行扩展，也可以实现多订阅者，不需要专门制定某一种模式。

同时，kafka相比于传统的消息系统，具有更好有序性。

传统的队列模型，将记录有序的存储在服务器上，当多个消费者消费队列中的消息时，服务器会按照顺序处理这些记录。虽然，服务是是顺序的处理这些记录的，但是由于是传输数据给多个消费者，当消费者接收到服务器的时间是，顺序可能已经被打乱。也就是说，在并行消费的模式下，记录的有序性将无法保证。消息系统经常使用“专属消费者”的概念来解决这个问题，只允许一个进程从队列中消费消息，这样就无法实现并行处理。

通过一个并行处理的概念-主题（topic）中的分区（partition），kafka在这方面做得更好，kafka可以同时支持有序性和负载均衡。这是通过将主题（topic）中的分区（partition）分配给消费群中的消费者来实现的，这样每个分区就会被群中的一个消费者所消费。以此来保证消费者是某个分区的唯一读者，并且按顺序消费数据。同时由于采用了多分区实现了消费者的负载均衡，需要注意的是，消费群中的消费者实例数量不能比分区数量多。

kafka作为存储系统

任何一个消息系统都可以实现生产者和消费者的解耦，也可以存储正在传输的消息。kafka与众不同，它是一个很好的存储系统。

数据写入kafka将被保存到磁盘上同时保持在副本中，kafka允许生产者等待返回确认，直到写入磁盘和副本都成功，才认为写入成功，否则认为写入失败。

kafka非常方便扩展，无论是的磁盘上有50KB还是50TB的持久化数据。

由于存储很重要，并允许客户控制读写位置，kafka可以被当作分布式文件系统使用，它是一个高性能、低延迟、高可靠可复制的日志存储系统。

kafka数据流处理

仅仅是读、写和存储数据是不够的，kafka的目的是能够实时处理数据。

在kafka中，流处理器可以从输入的主题（topic）中连续的获取数据流，并对输入进行一系列处理，同时产生连续的数据流到输出主题。

比如，零售的应用程序可能需要输入销售和出货量，根据输入数据计算出重新订购的数量和调整后的价格，然后输出到主题（topic）。

可以直接使用生产者和消费者的API进行简单的处理，但是，对于复杂的转换，kafka提供了一个完全集成的Stream API。这允许你构建程序，这些应用程序可以从流中把一些重要的计算分离出来，或者将流连接在一起。

这种机制可以解决这类应用程序的问题：复杂的数据处理，改变代码重新处理输入，有状态计算等。

Stream API建立在kafka核心单元之上：它使用生产者和消费者的API进行输入和输出，使用kafka存储有状态的数据，并使用组机制在一组流处理实例中容错。

综述

消息系统、数据存储和流处理的这种组合看起来很不一般，但是kafka作为流媒体平台来说这些都是必不可少的。像HDFS这样的分布式文件系统允许存储用于批处理的静态文件，实际上，这样的系统允许存储和处理过去的历史数据。

传统的企业消息系统可以处理在订阅后将到达的消息，以这种方式构建的应用程序可以处理即将到达的消息

kafka将这两种功能结合在一起，对于kafka的使用来说，这两种的结合对于流处理应用程序以及流数据管道来说都是非常重要的。

通过整合存储和低延迟订阅，流应用程序可以以相同的方式处理过去和将来的数据。这是一个单一的应用程序可以处理历史的，存储的数据，而不是在到达最后一个记录时结束，它可以随着未来数据的到达继续处理。这是一个广义的流处理概念，其中包含批处理以及消息驱动应用程序。同样，对于流数据管道，订阅到实时事件的组合使得可以用kafka处理非常低延迟的管道传输；可靠的存储数据的能力使得可以将其用于必须保证数据传输的关键数据，或者与离线系统集成，这些系统只能周期性的加载数据，或者可能会长时间停机以进行维护。流处理设备可以在数据到达时转换数据。有关kafka提供的保证，APIS和功能的更多信息，请参见文档其余部分。