Kafka介绍

Kafka介绍

ApacheKafka是一个分布式流媒体平台
流媒体平台有三个关键功能:

  • 发布和订阅记录流,类似于消息队列或企业消息传递系统。
  • 以容错的持久方式存储记录流。
  • 处理发生的记录流。

Kafka通常用于两大类应用程序:

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

首先有几个概念:
Kafka作为集群运行在一个或多个服务器上,这些服务器可以跨多个数据中心。
Kafka集群将记录流存储在称为主题的类别中。每个记录由一个键、一个值和一个时间戳组成。
在Kafka中,客户机和服务器之间的通信是通过一个简单的、高性能的、与语言无关的TCP协议完成的。此协议经过版本控制,并与旧版本保持向后兼容性。官方为Kafka提供了一个Java客户机,但是客户机可以使用多种语言。

Kafka有四个核心API:

  1. Producer API 允许应用程序向一个或多个Kafka主题发布记录流。
  2. Consumer API 允许应用程序订阅一个或多个主题,并处理生成给它们的记录流。
  3. Streams API 允许应用程序充当流处理器,使用来自一个或多个主题的输入流,并将输出流生成到一个或多个输出主题,从而有效地将输入流转换为输出流。
  4. Connector API 允许构建和运行将Kafka主题连接到现有应用程序或数据系统的可重用生产者或消费者。例如,连接到关系数据库的连接器可能捕获对表的每个更改。

Topics and Logs 主题与日志

让我们首先深入了解Kafka为记录流提供的核心抽象—主题。主题是发布记录的类别或提要名称。
Kafka中的主题通常是多订阅者的;也就是说,主题可以有0个、1个或多个订阅写入主题的数据的使用者。

对于每个主题,Kafka集群都维护一个分区日志,如下所示:
图片来自官网
每个分区都是一个有序的、不可变的记录序列,这些记录不断地添加到结构化提交日志中。每个分区中的记录都被分配一个顺序的id号,称为惟一标识分区中的每个记录的偏移量。

Kafka集群使用一个可配置的保留期持久地保存所有已发布的记录(不管它们是否已被消耗)。例如,如果保留策略设置为2天,那么在发布记录后的2天内,记录是可用的,在此之后将丢弃记录以释放空间。Kafka的性能在数据大小方面实际上是恒定的,因此长时间存储数据不是问题。

在这里插入图片描述
实际上,在每个使用者的基础上保留的唯一元数据是该使用者在日志中的偏移量或位置。这个偏移量由使用者控制:通常情况下,使用者在读取记录时将线性地推进其偏移量,但实际上,由于位置由使用者控制,所以它可以按照自己喜欢的任何顺序消费记录。例如,使用者可以重置到旧的偏移量来重新处理过去的数据,或者跳到最近的记录并从“现在”开始消费。

日志中的分区有几个用途。首先,它们允许日志扩展到超出单个服务器的大小。每个单独的分区必须适合承载它的服务器,但是主题可能有多个分区,因此可以处理任意数量的数据。其次,它们作为并行的单位

Distribution分配

日志的分区分布在Kafka集群中的服务器上,每个服务器处理分区共享的数据和请求。为了容错,每个分区在可配置数量的服务器之间复制。
每个分区都有一个服务器充当“leader”,还有零个或多个服务器充当“follower”。leader处理分区的所有读写请求,而follower则被动地复制leader。如果领导者失败,其中一个追随者将自动成为新的领导者。每个服务器作为它的一些分区的领导者和其他分区的追随者,因此负载在集群中得到很好的平衡。

Geo-Replication 复制备份

Kafka MirrorMaker为集群提供地理复制支持。使用MirrorMaker,可以跨多个数据中心或云区域复制消息。可以在用于备份和恢复的主动/被动场景中使用它;或者在主动/主动场景中,将数据放置在离用户更近的地方,或者支持数据局部性需求。

Producers生产者

生产者将数据发布到他们选择的主题。生产者负责选择要分配给主题中的哪个分区的记录。为了平衡负载,采用循环方式来完成,也可以根据一些语义划分函数(比如基于记录中的某个键)来完成。

Consumers消费者

消费者用一个消费者组名给自己打上标签,发布到主题的每个记录都被交付给每个订阅消费者组中的一个消费者实例。消费者实例可以位于单独的进程中,也可以位于单独的机器上。

如果所有消费者实例具有相同的消费者组,则记录将有效地在消费者实例上进行负载平衡。
如果所有消费者实例具有不同的消费者组,则每个记录将广播到所有消费者进程。

在这里插入图片描述
上图所示:两个服务器Kafka集群承载四个分区(P0-P3)和两个消费组。使用者组A有两个消费者实例,而消费者组B有四个消费者实例。

然而,更常见的是,我们发现主题有少量的消费者组,每个“逻辑订阅者”对应一个。每个组由许多用于可伸缩性和容错的消费者实例组成。这只不过是发布-订阅语义,其中订阅者是一组消费者,而不是单个进程。

在Kafka中实现消费的方式是将日志中的分区划分到消费者实例上,这样每个实例在任何时间都是分区“公平共享”的消费者。这个维护组成员关系的过程是由Kafka协议动态处理的。如果新实例加入组,它们将接管组中其他成员的一些分区;如果一个实例死亡,它的分区将被分配给其余的实例。Kafka只提供分区内记录的总顺序,而不是主题中不同分区之间的顺序。对于大多数应用程序来说,每个分区的排序和按键划分数据的能力已经足够了。但是,如果需要记录上的总顺序,那么可以使用只有一个分区的主题来实现,这就意味着每个消费者组只有一个消费者进程。

Kafka as a Messaging System 作为一个消息系统

消息传递传统上有两种模型:队列发布-订阅
在队列中,一组使用者可能从服务器读取数据,每条记录转到其中一条;
在发布-订阅中,记录被广播给所有的消费者。
这两种模式各有优缺点。
队列的优势在于,它允许您将数据处理划分到多个消费者实例上,从而可以伸缩处理。但是,一旦一个进程读取了它丢失的数据,队列并不是多订阅者。
发布-订阅允许将数据广播到多个进程,但无法扩展处理,因为每个消息都要发送到每个订阅者。
Kafka的消费群体概念概括了这两个概念。与队列一样,使用者组允许在一组进程(消费者组的成员)上划分处理。与发布-订阅一样,Kafka允许向多个消费者组广播消息。
Kafka的优点是每个主题都有这两个属性,它可以扩展处理,而且是多订阅者,不需要选择其中之一。
Kafka也比传统的消息系统有更强的订购保证。
传统队列在服务器上按顺序保留记录,如果多个使用者从队列中消费记录,那么服务器将按存储记录的顺序分发记录。然而,尽管服务器按顺序分发记录,但这些记录是异步传递给使用者的,因此它们可能在不同的使用者上顺序不一致。这实际上意味着在并行消费的情况下,记录的顺序会丢失。
消息传递系统通常通过“独占使用者”的概念来解决这一问题,该概念只允许一个进程从队列中消费,但这当然意味着在处理中不存在并行性。kafka则通过对主题中的分区的并行性概念的进行处理,能够在用户进程池上提供排序保证和负载平衡。这是通过将主题中的分区分配给消费者组中的消费者来实现的,以便每个分区都由该组中的一个消费者使用。通过这样做,我们确保消费者是该分区的唯一读者,并按顺序使用数据。但是请注意,在一个消费者组中,消费者实例不能多于分区。

Kafka as a Storage System 作为存储系统

任何允许发布与使用分离的消息的消息队列都有效地充当动态消息的存储系统。kafka的不同之处在于它是一个非常好的存储系统。

写入Kafka的数据被写入磁盘并进行复制以实现容错。Kafka允许生产者等待确认,这样写入就不会被认为是完整的,直到它被完全复制,并保证即使写入的服务器失败也会保持。

Kafka使用的磁盘结构具有良好的伸缩性,无论服务器上有50 KB还是50 TB的持久数据,Kafka都将执行相同的操作。

Kafka for Stream Processing 用于流处理

仅仅读取、写入和存储数据流是不够的,其目的是支持流的实时处理。
在Kafka中,流处理器是从输入主题中获取连续的数据流,对该输入执行一些处理,并生成连续的数据流以输出主题。
kafka可以直接使用生产者api和消费者api进行简单的处理。然而,对于更复杂的转换,Kafka提供了一个完全集成的Streams API。这允许构建进行非琐碎处理的应用程序,计算流的聚合或将流连接在一起。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值