Kafka学习记录一：Kafka介绍

参照官方文档开始Kafka学习

介绍

Apache Kafka是一个分布式的流媒体平台。

流媒体平台有三个关键的功能：

• 发布和订阅记录流，类似于一个消息队列或者企业信息系统。
• 以容错的持久方式存储记录流。
• 实时处理记录流。

Kafka通常用于两大类应用：

• 构建可在系统或应用程序之间获取数据的的实时流数据管道
• 构建转换或响应数据流的实时流应用程序

在理解Kafka是如果做到这些事情之前，首先需要了解几个概念

• Kafka作为集群运行在一台或者多台可以跨多个数据中心的服务器上。
• Kafka集群在名为主题（Topic）的分类中存储记录流。
• 每一条记录由一个Key、一个Value和一个timestamp组成。

Kafka有四个核心的API：

• Producer API：生产者API允许应用程序去发布数据流到一个或者多个Kafka主题。
• Consumer API：消费者API允许应用程序定于一个或者多个主题并处理为这些主题生成的记录流。
• Streams API：流处理API允许应用程序作为流处理器，消费从一个或者多个主题中的输入流并生成到一个输出流到一个或者多个输出主题中，从而有效的将输入流转换为输出流。
• Connector API：连接器API允许构建和运行那些连接Kafka主题到已存在的应用程序或者数据系统的可复用的生产者或消费者 。例如，关系型数据库的连接器可能捕获对表的每个改变。
  
  在Kafka中，客户端和服务器之间的通信是通过简单，高性能，语言无关的的TCP协议完成。此协议是版本化并且保持与旧版本的兼容。

Topics and Logs(主题与日志)

首先先深入探讨Kafka提供的对记录流的核心抽象-topic （主题）。
主题是已经发布的记录的类别或者订阅源名称。Kafka的主题总是多用户的，意味着，一个主题可以有0个，1个或者多个的消费者去订阅写入它的数据。
对于每一个主题，Kafka集群都会维护着一个如下图所示的分区日志：

每一个分区都是一个有序的，不变的记录序列，不断添加到一个结构化的提交日志中。分区中的每个记录都分配了一个称为*offset（偏移）*的序列ID，它是每个记录在分区中的的唯一性标识。
Kafka集群持久化所有分布的记录-不管这些记录是否已经被消费-使用一个可配置的保存期。例如，如果保存策略设置为两天，则在记录发布后的两天内，它都是可供使用的，之后则会被丢弃从而释放空间。Kafka的性能在数据大小方面实际上是恒定的，因此长时间存储数据不是问题。

事实上，每一个消费者保留的唯一元数据是该消费者在日志中的偏移或者位置。这种偏移是由消费中控制的：通常消费者在读取记录的时候会线性地提供其偏移量，但是，实际上，因为位置是由消费者控制的，所以它可以按照自己喜欢的任意顺序消费记录。例如，一个消费者能够重置为一个旧的偏移量来重新处理过去的数据，或者跳到最近的记录并从“现在”开始消费。

这些功能组合意味着Kafka消费者非常廉价-他们的来来往往对于集群或者其他消费者没有太大的影响。例如，你能够使用命令行工具去查看任何主题结尾的数据而不会改变其他已经存在的消费者所消费的内容。

日志中的分区有多种用途。首先，它们允许日志扩展到超出适合单个服务器的大小。每个独立的分区必须适合托管它的服务器，但主题可以有多个分区，因此它可以处理任意数量的数据。更重要的是这一点：它们充当了并行性的单位。

Distribution(分布)

日志的分区分布在Kafka集群的集群中的服务器上，每一个服务器处理共享分区的数据和请求。每一个分区在课配置数量的服务器上进行复制，以实现容错。
每个分区都有一个服务器充当“leader（领导者）”，另个或者多个服务器充当“followers(追随者)”。领导者处理分区的所有读写请求，而追随者被动地复制领导者。如果领导者出现问题而导致失败，则其中一个追随者自动成为一个新的领导者。每一个服务器作为一些分区的领导者和其服务器的追随者从而到达集群中的负载均衡。

Geo-Replication(地域复制)

Kafka MirrorMaker（Kafka MirrorMaker是Kafka跨集群同步工具）为你的集群提供了地域复制的支持。使用MirrorMaker，消息可以跨多个数据中心或云区域进行复制。你可以使在主动/被动的方案中使用它进行备份和回复；或者在主动/被动的方案中，将数据放置在离用户较近的位置或支持的数据位置要求。

Producers(生产者)

生产者将数据发布到他们选择的主题中。生产者负责选择将记录分配给主题中的哪个分区之中。这些可以以循环方式完成，仅仅为了平衡负载，或者可以根据一些语义分区功能（例如基于记录中的某些key）。

Consumers(消费者)

消费者是用消费组名称标记自己，发布到主题中的每一条记录都被传递到每一个订阅了主题的消费组中的一个消费者实例。消费者实例可以在不同的的进程中，也可以在不同的机器中。
如果所有的消费者实例都在相同的消费组中，那么记录将会有效的消费者实例上进行负载均衡。
如果所有的消费者实例具有不同的消费组，那么每一条记录会广播到所有的消费者进程中。

如上图所示，两台服务器的Kafka集群持有包含4个分区（P0-P3)的两个消费组。消费组A有2个消费者实例，消费组B有4个消费组实例。
更常见的是，我们发现主题具有少量的消费者组，每一个都是一个“逻辑订户”。每个组是由许多可用于可扩展和容错的消费者实例组成。只不过是发布-订阅语义，其中的订阅者是消费者集群而不是单个进程。
在Kafka中实现消费的方式是通过在消费者实例上划分日志中的分区，以便每个实例在任何时间点都是“公平份额”的专有消费者。维护组中成员资格的过程是通过Kafka协议动态处理的。如果一个新实例加入该组，将会从该组的其他成员那接管一些分区；如果实例死亡，他的分区将会被分配给其余实例。
Kafka只提供了在分区中记录的顺序，而不是主题中所有分区之间的顺序。对大多数应用程序而言，通过结合按键去分区数据的能力进行排序就足够了。然而，如果需要对记录进行总排序，则可以使用仅包含一个分区的主题，尽管这就意味一个消费者组只有一个消费进程。

Multi-tenancy(多租户:单一软件程序为多个客户服务的架构)

能够将Kafka部署作为多租户的解决方案。通过配置哪些主题可以生成或消费数据来启用多租户。并且支持配额操作。管理员能够根据要求定义和执行配额去控制用户端使用的代理资源。

Guarantees(保证)

高级别Kafka提供了如下保证：

• 通过生产者发送到特定主题分区的消息将按发送顺序添加到分区。也就是说，如果记录M1和M2都是由相同的生产者发送，并且首先发送M1，那么M1相对于M2将有一个更低的偏移量，并且更早的添加到日志中。
• 一个消费者实例按照他们存储在日志中的顺序查看记录。
• 对于主题的重复因子N，则可以容忍最多N-1台服务器故障，而不丢失任何已经成功提交的日志中的记录。

Kafka as a Messaging System(Kafka作为消息系统)

Kafka的流概念与传统的企业消息系统比较：
消息传统上有两类模型：queuing（队列）和publish-subscribe（发布-订阅）。在队列中，消费者池可以从服务器读取并且每一个记录都读取到池中的某个消费者实例；在发布-订阅中，记录被广播到所有的消费者。这两种模型都有相应的优点和缺点。队列的优点是允许在多个消费者实例中划分数据处理过程，从而可以扩展处理，提高效率。但是队列不是多用户的，数据一旦被进程读取就消失了。发布-订阅模型允许你广播数据到多个进程中，但是无法进行扩展处理，因为每一个消息都被发送给每个订阅者。

Kafka中的消费组的概念概括了这两个概念。与队列模型一样，消费组允许你将处理划分为一组进程（即消费组的成员）。与发布-订阅模型一样，Kafka允许你广播消息到多个消费组。
Kafka模型的优势在于每个主题都具有这些属性-它既可以扩展处理，又是多用户的-而不需要选择其中一个。
与传统的消息系统相比，Kafka有更强的顺序保证。
传统队列在有序的保存记录在服务器上，如果多个消费者从队列中消费，服务器按存储顺序分发记录。然而，尽管服务器按顺序分发记录，因为记录分发给消费者是异步的，所以可能在不同的消费者那边到达顺序出现颠倒。这实际上意味着记录的顺序在并发消费的时候存在丢失。消息系统通常通过具有“唯一消费者”的概念来解决这个问题，该概念只允许一个进程从队列中消费，并且该进程中没有并行消费。
Kafka做的更好。通过在主题中具有并行性的概念-分区，Kafka能够在消费者进程池中同时提供顺序保证和负载均衡。这是通过在主题中将分区分配给消费组的消费者来实现的，其中每一个分区都是被在消费组中确定的一个消费者消费的。通过这么做，我们可以确保这个消费者是这个分区的唯一的读者并且按顺序消费数据。因为存在多个分区，所以依然可以通过多个消费者实例来实现负载均衡。但请注意，消费者组中的消费实例的数量不能超过分区的数量。

Kafka as a Storage System(Kafka作为存储系统)

任何允许发布消息脱离消费者的消息队列实际上都是作为一个正在进行的消息的存储系统。Kafka的不同之处在于它是个非常好的存储系统。
写入Kafka的数据将写入到磁盘中并进行复制以实现容错。Kafka允许生产者等待确认，以便在完全复制之前的写入不被认为是完整的，并保证即使服务器写入失败也进行持久化。
Kafka的规模很好地使用了磁盘结构-无论服务器上有50KB还是50TB的持久化数据，Kafka都会执行相同的操作。
由于认真对待存储并允许客户端控制其读取位置，可以将Kafka视为一种专用于高性能，低延迟提交日志存储，复制和传播的专用分布式文件系统。

Kafka for Stream Processing(Kafka作为流处理器)

仅仅读取，写入和存储数据流是不够的，目的是实现流的实时处理。
在Kafka中，流处理器是指从输入主题获取连续数据流，对此输入执行某些处理以及生成连续数据流以输出数据到主题中。
例如，零售应用程序可能会接收销售和发货的输入流，并输出重新排序后的流和根据此数据计算出的价格调整。
可以使用生产者和消费者API直接进行简单处理。但是，对于更复杂的转换，Kafka提供了完全集成好的Streams API。这允许构建执行复杂处理的应用程序，这些应用程序可以计算流的聚合或将流连接在一起。
此工具有助于解决此类应用程序面临的难题：处理无序数据，在代码更改时重新处理输入，执行有状态计算等。
流API构建在Kafka提供的核心原语上：它使用生产者和消费者API进行输入，使用Kafka进行有状态存储，并在流处理器实例之间使用相同的组机制来实现容错。

Putting the Pieces Together(集成所有功能)

消息传递，存储和流处理的这种组合可能看起来很不寻常，但它对于Kafka作为流媒体平台的作用至关重要。
像HDFS这样的分布式文件系统允许存储静态文件以进行批处理。实际上，这样的系统允许存储和处理过去的历史数据。
传统的企业消息系统允许处理订阅后到达的消息。以这种方式构建的应用程序是为了处理未来将会达到的数据。
Kafka结合了这两种功能，这种组合对于Kafka作为流媒体应用程序平台以及流数据管道的使用至关重要。
通过组合存储和低延迟订阅，流应用程序可以以相同的方式处理过去和未来的数据。也就是说，单个应用程序可以处理历史存储的数据，而不是在它到达最后一条记录时结束，它可以在未来数据到达时继续处理。这是包含批处理以及消息驱动应用程序的流处理的一般概念。
同样，对于流数据流水管道，订阅实时事件的组合使得可以将Kafka用于极低延迟的管道; 但是，能够可靠地存储数据使得可以将其用于必须保证数据传输的关键数据，或者与仅定期加载数据或可能长时间停机以进行维护的离线系统集成。 流处理设施可以在数据到达时对其进行转换。

参考官网 http://kafka.apache.org/intro