Kafka The Definitive Guide - 初识Kafka

最新推荐文章于 2023-05-09 16:09:23 发布

Geek_ymv

最新推荐文章于 2023-05-09 16:09:23 发布

阅读量424

点赞数

分类专栏： MQ

本文链接：https://blog.csdn.net/Geek_ymv/article/details/81259095

版权

MQ 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

初识Kafka

每个应用程序都会产生数据，包括日志消息、度量指标、用户活动记录、响应消息等。数据的点点滴滴都在暗示一些重要的事情，比如下一步行动的方向。我们把数据从源头移动到可以对它们进行分析处理的地方，然后把得到的结果应用到实际场景中，这样才能够确切的知道这些数据要告诉我们什么。比如我们每天在购物网站上浏览感兴趣的商品，浏览信息被转换成商品推荐，并实时展示给我们。

1.1 发布与订阅消息系统

我们先来了解发布与订阅系统的概念，并认识这个系统的重要性。数据（消息）的发送者（发布者）不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者（订阅者）订阅它们，以便接收特定类型的消息。发布与订阅系统一般会有一个broker，也就是发布消息的中心点。

1.2 Kafka

Kafka是一款基于发布与订阅的消息系统，它一般被称为“分布式提交日志”或者“分布式流平台”。Kafka的数据是按照一定顺序持久保存的，可以按需读取。此外Kafka的数据分布在整个系统中，具备数据故障保护和性能伸缩能力。

1.2.1 消息和批次

Kafka的数据单元被称为消息，可以把消息看成是数据库里的一个“数据行”或一条“记录”。消息由字节数组组成。消息可以有一个可选的元数据，也就是键（key）。键也是一个字节数组。当消息以一种可控的方式写入不同的分区时，会用到键。举个例子就是为键生成一个一致性散列值，然后使用散列值对主题分区进行取模，为消息选取分区，这样可以保证具有相同键的消息总是被写到相同的分区上。后面将详细介绍键的用法。
为了提高效率，消息被分批次写入Kafka。批次就是一组消息，这些消息属于同一个主题和分区。如果每一个消息都单独穿行于网络，会导致大量的网络开销，把消息分成批次传输可以减少网络开销。不过，这要在时间延迟和吞吐量之间作出权衡：批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储能力。但要做更多的计算处理。

1.2.2 模式

对于Kafka来说，消息不过是晦涩难懂的字节数组，所以有人建议用一些额外的结构来定义消息内容，让它们更易于理解。根据应用程序的需求，消息模式（schema）有许多可用的选项。像JSON和XML这些简单的系统，不仅易用，而且可读性好。不过它们缺乏强类型处理能力，不同版本之间的兼容性也不是很好。Kafka的许多开发者都喜欢使用Apache Avro，它最初是为Hadoop开发的一款序列化框架。Avro提供了一种紧凑的序列化格式，模式和消息体是分来的，当模式发生变化时，不需要重新生成代码；它还支持强类型和模式进化，其版本既向前兼容，也向后兼容。
数据格式的一致性对于Kafka来说很重要，它消除了消息读写操作之间的耦合性。如果读写操作紧密地耦合在一起，消息订阅者需要升级应用程序才能同时处理新旧两种数据格式。在消息订阅者升级了之后，消息发布者才能跟着升级，以便使用新的数据格式。新的应用程序如果需要使用数据，就要与消息发布者发生耦合，导致开发需要做很多繁杂的工作。定义良好的模式，并把它们存放在公共仓库，可以发方便我们理解Kafka的消息结构。

1.2.3 主题和分区

Kafka的消息通过主题进行分类。主题就好比数据库的表，或者文件系统里的文件夹。主题可以被分成若干个分区，一个分区就是一个提交日志。消息以追加的方式写入分区，然后以先入先出的顺序读取。要注意，由于一个主题一般包含几个分区，因此无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。如下图所示的主题有4个分区，消息被追加写入每个分区的尾部。Kafka通过分区来实现数据冗余和伸缩性。分区可以分布在不同的服务器上，也就是说，一个主题可以横跨多个服务器，以此来提供比单个服务器更强大的性能。
包含多个分区的主题
我们通常会使用流这个词来描述Kafka这类系统的数据。很多时候，人们把一个主题的数据看成一个流，不管它有多少个分区。流是一组从生产者移动到消费者的数据。当我们讨论流式处理时，一般都是这样描述消息的。Kafka Streams、Apache Samza和Storm这些框架以实时的方式处理消息，也就是所谓的流式处理。我们可以将流式处理与离线处理进行比较，比如Hadoop就是用于在某个时刻处理大量的数据。

1.2.4 生产者和消费者

Kafka的客户端就是Kafka系统的用户，分为两种类型：生产者和消费者。除此之外，还有其他高级客户端API——用于数据集成的Kafka Connect API和用于流式处理的Kafka Streams。这些高级客户端API使用生产者和消费者作为内部组件，提供了高级的功能。
生产者创建消息。一般情况下，一个消息会被发布到一个特定的主题上。生产者在默认情况下把消息均衡地分布到主题的所有分区上，而并不关系特定消息会被写到哪个分区。不过，在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。
消费者读取消息。消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在Zookeeper或Kafka上，如果消费者关闭或重启，它的读取状态不会丢失。
消费者是消费者群组的一部分，也就是说，会有一个或多个消费者共同读取一个主题。群组保证每个分区只能被一个消费者使用。如下图所示的群组中，有3个消费者同时读取一个主题。其中的两个消费者各自读取一个分区，另外一个消费者读取其他两个分区。消费者与分区之间的映射通常被称为消费者对分区的所有权关系。通过这种方式，消费者可以消费包含大量消息的主题。而且，如果一个消费者失效，群组里的其他消费者可以接管失效消费者的工作。

消费者群组从主题读取消息

1.2.5 broker和集群

一个独立的Kafka服务器被称为broker。broker接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个broker可以轻松处理数千个分区以及每秒百万级的消息量。
broker是集群的组成部分。每个集群都有一个broker同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。控制器负责管理工作，包括将分区分配给broker和监控broker。在集群中，一个分区从属于一个broker，该broker被称为分区的首领。一个分区可以分配给多个broker，这个时候会发生分区复制（如下图）。这种复制机制为分区提供了消息冗余，如果有一个broker失效，其他broker可以接管领导权。不过相关的消费者和生产者都要重新连接到新的首领。
集群里的分区复制
保留消息（在一定期限内）是Kafka的一个重要特性。Kafka broker默认的消息保留策略：要么保留一段时间（比如7天），要么保留到消息到达一定大小的字节数（比如1GB）。当消息数量达到这些上限时，旧消息就会过期并被删除，所以在任何时刻，可用消息总量都不会超过配置参数所指定的大小。主题可以配置自己的保留策略，可以将消息保留到不再使用它为止。

1.3 为什么选择Kafka

基于发布与订阅的消息系统那么多，为什么Kafka会是一个更好的选择呢？

1.3.1 多个生产者

Kafka可以无缝地支持多个生产者，不管客户端在使用单个主题还是多个主题。所以它很适合用来从多个前端系统收集数据，并以统一的格式对外提供数据。例如，一个包含了多个微服务的网站，可以为页面视图创建一个单独的主题，所有服务都以相同的消息格式向该主题写入数据。消费者应用程序会获得统一的页面视图，而无需协调来自不同生产者的数据流。

1.3.2 多个消费者

Kafka也支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响。这与其他队列系统不同，其他队列系统的消息一旦被一个客户端读取，其他客户端就无法再读取它。另外，多个消费者可以组成一个群组，它们共享一个消息流，并保证整个群组对每个给定的消息只处理一次。

1.3.3 基于磁盘的数据存储

Kafka不仅支持多个消费者，还允许消费者非实时地读取消息，这要归功于Kafka的数据保留特性。消息被提交到磁盘，根据设置的保留规则进行保存。每个主题可以设置单独的保留规则，以便满足不同消费者的需求，各个主题可以保留不同数量的消息。消费者可能会因为处理速度慢或突发的流量高峰导致无法及时读取消息，而持久化数据可以保证数据不会丢失。消费者可以在进行应用程序维护时离线一小段时间，而无需担心消息丢失或堵塞在生产者端。消费者可以被关闭，但消息会继续保留在Kafka里。消费者可以从上次中断的地方继续处理消息。

1.3.4 伸缩性

为了能够轻松处理大量数据，Kafka从一开始就被设计成一个具有灵活伸缩性的系统。用户在开发阶段可以先使用单个broker，再扩展到包含3个broker的小型开发集群，然后随着数据量不断增长，部署到生产环境的集群可能包含上百个broker。对在线集群进行扩展丝毫不影响整体系统的可用性。也就是说，一个包含多个broker的集群，即使个别broker失效，仍然可以持续地为客户提供服务。要提供集群的容错能力，需要配置较高的复制系数。