1.1、简介
ApacheKafka®是一个分布式流媒体平台。 这到底是什么意思呢？
- 它可以让你发布和订阅消息流。 在这方面，它类似于消息队列或企业消息传递系统。
- 它允许您以容错方式存储消息流。
- 它可以让你处理产生的流式消息。
Kafka的优势在哪里？
- 在系统或应用程序之间构建可靠的实时数据流管道
- 构建实时流应用程序，可以转换或响应数据流
要理解kafka必须要了解一下概念：
- Kafka在一个或多个服务器上的集群运行。
- Kafka集群以叫做主题（topic）的类别存储记录流。
- 每个记录（消息）由一个键，一个值和一个时间戳组成。
Kafka有四个核心API：
- Producer API允许应用程序将一组记录发布到一个或多个Kafka主题。
- Consumer API允许应用程序订阅一个或多个主题并处理产生给他们的消息流。
- Streams API允许应用程序充当流处理器，从一个或多个主题中消费输入流，并将输出流生成为一个或多个输出主题，从而将输入流有效地转换为输出流。
- Connector API允许构建和运行可重复使用的生产者或消费者，将Kafka主题连接到现有的应用程序或数据系统。 例如，连接到关系数据库的连接器可能会捕获对表的每个更改。
在Kafka中，客户端和服务器之间的通信是通过一个简单的，高性能的，与编程语言无关的TCP协议完成的。 这个协议是版本化的，并保持与旧版本的向后兼容性。 我们为Kafka提供了一个Java客户端，但客户端可以使用多种语言。
主题和日志
让我们先深入kafka为消息流提供的一个核心抽象- 主题（topic）。
Topic是消息发布到哪一个类别或者提要的名称。Kafka的主题可以是多订阅模式的，也就是说一个主题可以有0个、1个或者多个消费者去消费写入该主题的数据。
对于每个主题，Kafka集群维护一个分区日志，如下所示：
每个分区是一个有序的，不可变的消息序列，不断追加到结构化的提交日志（文件）中。 分区中的每个消息分配一个连续的id号，称为偏移量（offset），用于唯一标识分区内的每条消息。
Kafka集群使用可配置的保留期限来保留所有已发布的消息（无论是否已被使用）。 例如，如果保留策略设置为两天，则在消息发布后的两天内，消息可以可供使用，之后将被丢弃以腾出空间。Kafka性能对数据大小不敏感，所以长时间存储数据不成问题。
实际上，以消费者为单位保留的唯一元数据是消费者在日志中的偏移或位置。这个偏移量是由消费者控制的：消费者通常会在读取记录时线性地推进其偏移量，但事实上，由于消费者的位置是由消费者控制的，所以它可以以任何喜欢的顺序消费记录。例如，消费者可以重置为较早的偏移量以重新处理过去的数据，或者跳至最近的记录并从“现在”开始消费。
这些功能的组合意味着Kafka的消费者非常轻便 - 他们可以来来去去，对集群或其他消费者没有太大的影响。例如，您可以使用我们的命令行工具来“tail”任何主题的内容，而不会更改任何现有消费者使用的内容。
日志中的分区有几个用途。 首先，它们允许日志的大小超出适合单个服务器的存储限制。 每个单独的分区必须适合存放它的服务器，但是一个主题可能有许多分区，因此它可以处理任意数量的数据。 其次，更重要的是，它们是作为并行处理的单位。
分布式
日志的所有有分区被分发到集群中的服务器上，每个服务器处理全部分区中的部分分区数据和请求。为了容错，每个分区都被复制到一定数量（可配置）的不同服务器上。
每个分区（有多个副本）都有一台服务器作为“leader”，大于等于0台服务器做为”followers”。”leader”服务器处理分区的所有读写操作。”followers”服务器对当前分区做为旁观者，什么都不做。当”leader”服务器不可用时，那么”followers”中的一台将自动成为”leader”。每台服务器都即做为一些分区的”leader”，又做为其它分区的“followers”。
生产者
生产者向所选的主题发布数据。生产者负责选择哪些消息应该分配到主题内的哪个分区。这种选择分区方式，可以使用简单的循环方式来负载均衡； 也可以通过一些语义分区函数实现（如：基于消息的key的hash等），更多的是第二种情况来使用分区。
消费者
传统的消息处理有两种模型：队列和发布订阅。队列模式，消费者池中的消费者可以从一台服务器读数据，并且每个消息只被其中一个消费者消费。发布订阅模式，消息通过广播方式发送给所有消费者。kafka提供了一个单一的抽象概念，可以满足这两种（队列、发布订阅）模式－－消费者组。
消费者通过分组名（group name）标识自己，每条消息被发布到主题，并只会分发给消费者组中的 唯一个 消费者实例（即只被组中的一个消费者消费）。这些消费者即可以是同一台服务器上不同的进程，也可以是位于不同服务器上进程。
如果所有的消费者实例属于同一分组（相同的分组名），那么这就是传统的队列模式（相同topic，只有一个消费者能抢到消息）。
如果所有的消费者实例不属于同一分组，那么这就是发布订阅模式（每个消费者都能收到消息）
两个服务器Kafka集群管理四个分区（P0-P3）与两个消费者组。消费者组A有两个消费者实例，而组B有四个消费者实例。
然而，更普遍的是，topic只有少量的消费组，每个“逻辑订阅者”都有一个消费组。每个组由许多消费者实例组成，具有可扩展性和容错性。这就是发布-订阅模式，订阅者是一群消费者而不是一个进程。
传统队列维护消息顺序性。如果多个消费者从队列中消费消息，那么服务器以存储的顺序分发消息。虽然消息从服务器出队列是按顺序的，但是被分发给消费者时，是通过异步的方式，因此消息到达不同消费者时可能是乱序的。这意味者并发消费时，消费是乱序的。消息系统为了做到这点，会采用只有一个消费者消费的理念，但这也意味是无法并行操作。
kafka这点做的更好，通过称为分区（主题内）的并行概念，kafka即可以提供顺序又可以负载均衡。这是通过给主题内的相同分组下的消费者提供多个分区的架构，来实现每个分区只能被一个消费者消费。通过这种方式，可以确保同一分区只有一个消费者，因此一个分区消费消息是顺序的； 同时，由于有多个分区，因此可以负载均衡。注意：一个分组内，消费者数量不能多于分区数量。此处的：不能多于，不是绝对。即：一个应用集群（有消费者）可能远远多于分区数量，只能说超出的消费者永远都无分区消费，但并不影响其它消费者正常使用。
kafka仅仅支持分区内的消息顺序消费，并不支持全局（同一主题的不同分区之间）的消息顺序。每个分区排序与根据消息key进行数据分区的能力相结合，足以满足大多数应用程序的需求。 但是，如果你需要一个全局顺序消费消息，你可以通过一个主题只有一个分区的方法实现，但是这也意味着一个分组只有一消费者。
保证
一个高级的kafka提供以下保证：
- 由生产者发送到特定主题分区的消息将按照它们发送的顺序添加。 也就是说，如果记录M1和记录M2由同一个生产者发送，并且M1被首先发送，则M1将具有比M2更低的偏移量值并且出现在日志中较早的地方。
- 消费者实例按照存储在日志中的顺序查看记录。
- 对于具有复制因子（replication factor）N的主题，我们将容忍多达N-1个服务器故障，而不会丢失任何提交给日志的记录。
有关这些保证的更多细节在文档的设计章节。
kafka作为消息系统
Kafka的流概念如何与传统的企业消息系统相比较？
消息传统上有两种模式：队列和发布-订阅。在队列中，消费者池可以从服务器读取并且每条消息只去往其中的一个;在发布-订阅中消息被广播给所有消费者。这两种模式都有其优点和缺点。队列的优势在于它允许您将数据处理划分为多个消费者实例，这样可以扩展处理。不幸的是，队列不是多订阅的，一旦一个进程读取了数据它就消失了。发布-订阅允许您将数据广播到多个进程，但无法进行扩展处理，因为每条消息都发送给每个订阅者。
Kafka的消费群体概念包含了这两个概念。与队列一样，消费者组允许您将一系列流程（消费者组的成员）的处理分开。与发布-订阅一样，Kafka允许您向多个消费者群体广播消息。
Kafka模型的优点是每个主题都具有这些属性 - 它可以扩展处理，也可以是多订阅 - topic不需要选择其中一个。
Kafka也比传统的消息系统有更强的顺序保证。
传统队列在服务器上按顺序保留记录，并且如果多个消费者从队列中消费，则服务器按照它们存储的顺序取出记录。但是，虽然服务器按顺序取出记录，但是记录是异步传递给消费者的，所以不同的消费者可能不是按照顺序收到消息。这实际上意味着记录的排序在并行消耗的情况下丢失。消息传递系统通常具有“排他消费者”的属性，只允许一个进程从队列中消耗，但这当然意味着在处理中没有并行处理能力。
Kafka做得更好。 通过在主题内部有一个并行的概念 - 分区，Kafka能够提供排序保证和负载平衡。 这是通过将主题中的分区分配给使用者组中的使用者来实现的，以便每个分区仅由组中的一个使用者使用。 通过这样做，我们确保消费者是该分区的唯一消费者，并按顺序使用这些数据。 由于有很多分区，这仍然可以平衡许多消费者实例的负载。 但请注意，消费群组中的消费者实例不能多于分区。
卡夫卡作为存储系统
任何允许将消息发布出去的消息队列都可以充当存储系统。 Kafka的不同之处在于它是一个非常好的存储系统。
数据写入kafka时被写入到磁盘, 并复制到其他服务器上进行容错, kafka允许生产者只有在消息已经复制完, 并存储后才得到写成功的通知, 否则就认为失败.
kafka也很有效率利用了磁盘结构–无论你存储的是50KB或50TB的数据在kafka上, kafka都会有同样的性能
由于严谨的考虑存储并允许客户端控制其读取位置，所以可以将Kafka视为专用于高性能，低延迟提交日志存储，复制和传播的专用分布式文件系统。
kafka作为数据流处理
只读取，写入和存储数据流是不够的，目的是允许流的实时处理。
kafka的流数据处理器是持续从输入的topic读取连续的数据流, 进行数据处理, 转换, 后产生连续的数据流输出到topic中
例如，零售应用程序可能会接受输入的销售和发货流，并输出一系列重排序的数据并针对这些数据的计算进行价格调整。
直接使用生产者和消费者API可以做简单的处理。但是对于更复杂的转换，Kafka提供了一个完全集成的Streams API。这允许构建应用程序进行非一般的处理，从而对流进行聚合或者join另外一个流。
这个工具有助于解决这类应用程序面临的难题：处理乱序数据，重新处理代码更改的输入，执行有状态的计算等等。
流API基于Kafka提供的核心原函数构建：它使用生产者和消费者API进行输入，使用Kafka进行有状态存储，并在流处理器实例之间使用相同的组机制来实现容错。
整合
消息传递，存储和流处理的这种组合可能看起来很不寻常，但对于Kafka作为一个流媒体平台来说，这是非常重要的。
像HDFS这样的分布式文件系统允许存储用于批处理的静态文件。这样的系统可以有效地存储和处理过去的历史数据。
传统的企业消息系统只允许处理在你订阅之后到达的数据，以这种方式构建的应用程序处理在将来到达的数据。
Kafka结合了这两种功能，而且这两种组合对于Kafka用作流应用平台以及流式传输数据管道都是至关重要的。
通过将存储和低延迟订阅相结合，流式应用程序可以同样的方式处理历史和未来的数据。一个应用可以处理历史存储的数据, 也可以在读到最后记录后, 保持等待未来的数据进行处理。这是流处理的概括概念，包括批处理以及消息驱动的应用程序。
