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性能对数据大小不敏感,所以长时间存储数据不成问题。
image.png
实际上,以消费者为单位保留的唯一元数据是消费者在日志中的偏移或位置。这个偏移量是由消费者控制的:消费者通常会在读取记录时线性地推进其偏移量,但事实上,由于消费者的位置是由消费者控制的,所以它可以以任何喜欢的顺序消费记录。例如,消费者可以重置为较早的偏移量以重新处理过去的数据,或者跳至最近的记录并从“现在”开始消费。
这些功能的组合意味着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用作流应用平台以及流式传输数据管道都是至关重要的。
通过将存储和低延迟订阅相结合,流式应用程序可以同样的方式处理历史和未来的数据。一个应用可以处理历史存储的数据, 也可以在读到最后记录后, 保持等待未来的数据进行处理。这是流处理的概括概念,包括批处理以及消息驱动的应用程序。
网友评论