Apache Kafka简介_docker安装kafka(1)，大数据开发开发大佬的百度美团快手等大厂Offer收割之旅

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

// specify connection properties
Properties props = new Properties();
props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, “localhost:9092”);
props.put(ConsumerConfig.GROUP_ID_CONFIG, “MyFirstConsumer”);
props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
// receive messages that were sent before the consumer started
props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, “earliest”);
// create the consumer using props.
try (final Consumer<Long, String> consumer = new KafkaConsumer<>(props)) {
    // subscribe to the topic.
    final String topic = “my-first-topic”;
    consumer.subscribe(Arrays.asList(topic));
    // poll messages from the topic and print them to the console
    consumer
      .poll(Duration.ofMinutes(1))
      .forEach(System.out::println);
}

当然，这是一种Kafka Client在Spring中的集成。

4. 基础概念

4.1 生产者&消费者

我们可以将 Kafka 客户端区分为消费者和生产者。 生产者向 Kafka 发送消息，而消费者则从 Kafka 接收消息。 他们仅通过主动从 Kafka 轮询来接收消息。 卡夫卡本身就是在以被动的方式行事。 这使得每个消费者都有自己的性能，而不会阻塞 Kafka。

当然，可以同时有多个生产者和多个消费者。当然，一个应用程序可以同时包含生产者和消费者。

消费者是消费者组的一部分，Kafka 通过一个简单的名称来识别消费者组。一个消费者组中只有一个消费者会收到该消息。这允许在保证仅一次消息传递的情况下扩展消费者。

下图是多个生产者和消费者与Kafka一起工作的情况：

4.2 消息

消息（我们也可以将其命名为“记录”或“事件”，具体取决于用例）是 Kafka 处理的数据的基本单位。 其有效负载可以是任何二进制格式以及纯文本、Avro、XML 或 JSON 等文本格式。

每个生产者都必须指定一个序列化器来将消息对象转换为二进制有效负载格式。 每个消费者必须指定相应的反序列化器来将有效负载格式转换回其 JVM 中的对象。 我们将这些组件简称为 SerDes。 有内置的 SerDes，但我们也可以实现自定义 SerDes。

下图展示了payload的序列化和反序列化过程：

此外，消息可以具有以下可选属性：

• 密钥也可以是任何二进制格式。 如果我们使用密钥，我们还需要 SerDes。 Kafka 使用键进行分区（我们将在下一章更详细地讨论这一点）。
• 时间戳指示消息的生成时间。 Kafka 使用时间戳来排序消息或实施保留策略。
• 我们可以应用标头将元数据与有效负载相关联。 例如。 Spring 默认添加用于序列化和反序列化的类型标头。

4.3 主题&分区

主题是生产者发布消息的逻辑通道或类别。消费者订阅一个主题以从其消费者组的上下文中接收消息。

默认情况下，主题的保留策略为 7 天，即 7 天后，Kafka 会自动删除消息，与是否发送给消费者无关。如果需要的话我们可以进行配置。

主题由分区（至少一个）组成。 确切地说，消息存储在主题的一个分区中。 在一个分区内，消息会获得一个顺序号（偏移量）。 这可以确保消息以与存储在分区中相同的顺序传递给消费者。 而且，通过存储消费者组已经收到的偏移量，Kafka 保证只传递一次。

通过处理多个分区，我们可以确定 Kafka 可以在消费者进程池上提供排序保证和负载平衡。

一个消费者在订阅该主题时将被分配到一个分区，例如 使用 Java Kafka 客户端 API，正如我们已经看到的：

String topic = “my-first-topic”; consumer.subscribe(Arrays.asList(topic));

However, for a consumer, it is possible to choose the partition(s) it wants to poll messages from:

TopicPartition myPartition = new TopicPartition(topic, 1);
consumer.assign(Arrays.asList(myPartition));

此变体的缺点是所有组消费者都必须使用它，因此自动将分区分配给组消费者将无法与连接到特殊分区的单个消费者结合使用。 此外，如果架构发生变化（例如向组中添加更多消费者），则无法进行重新平衡。

理想情况下，我们拥有与分区一样多的消费者，以便每个消费者都可以准确地分配给其中一个分区，如下所示：

如果我们的消费者多于分区，这些消费者将不会从任何分区接收消息：

如果我们的消费者少于分区，消费者将从多个分区接收消息，这与最佳负载平衡相冲突：

生产者不一定只向一个分区发送消息。每条生成的消息都会自动分配到一个分区，遵循以下规则：

• 生产者可以指定分区作为消息的一部分。 如果这样做，这具有最高优先级
• 如果消息有密钥，则通过计算密钥的哈希值来完成分区。 具有相同哈希值的密钥将存储在同一分区中。 理想情况下，我们至少拥有与分区一样多的哈希值
• 否则，粘性分区器将消息分发到分区

同样，将消息存储到同一分区将保留消息顺序，而将消息存储到不同分区将导致无序但并行处理。

如果默认分区不符合我们的期望，我们可以简单地实现一个自定义分区器。 因此，我们实现Partitioner接口并在生产者初始化时注册它：

Properties producerProperties = new Properties();
// …  
producerProperties.put(ProducerConfig.PARTITIONER_CLASS_CONFIG, MyCustomPartitioner.class.getName());
KafkaProducer<String, String> producer = new KafkaProducer<>(producerProperties);

下图展示了生产者和消费者以及他们与分区的连接：

每个生产者都有自己的分区器，因此如果我们想确保消息在主题内一致地分区，我们必须确保所有生产者的分区器以相同的方式工作，或者我们应该只与单个生产者一起工作。

分区按照消息到达 Kafka 代理的顺序存储消息。 通常，生产者不会将每条消息作为单个请求发送，而是会在一批中发送多条消息。 如果我们需要确保消息的顺序以及在一个分区内只传递一次，我们需要事务感知的生产者和消费者。

4.4 集群和分区副本

正如我们所发现的，Kafka 使用主题分区来允许并行消息传递和消费者的负载平衡。 但 Kafka 本身必须具有可扩展性和容错性。 因此，我们通常不使用单个 Kafka Broker，而是使用多个 Broker 组成的集群。 这些代理的行为并不完全相同，但它们中的每一个都被分配了特殊的任务，如果一个代理发生故障，集群的其余部分可以承担这些任务。

为了理解这一点，我们需要扩大对主题的理解。 创建主题时，我们不仅指定分区的数量，还指定使用同步共同管理分区的代理的数量。 我们称之为复制因子。 例如，使用 Kafka CLI，我们可以创建一个具有 6 个分区的主题，每个分区在 3 个代理上同步：

sh kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-replicated-topic --partitions 6 --replication-factor 3

例如，复制因子为 3 意味着集群对于最多两次副本故障具有弹性（N-1 弹性）。 我们必须确保我们至少拥有与指定的复制因子一样多的代理。 否则，Kafka 不会创建主题，直到代理数量增加。

为了提高效率，分区的复制仅发生在一个方向。 Kafka 通过将其中一个代理声明为分区领导者来实现这一目标。 生产者仅向分区领导者发送消息，然后领导者与其他代理进行同步。 消费者还将向分区领导者进行轮询，因为不断增加的消费者组的偏移量也必须同步。

分区领先被分配给多个经纪人。 Kafka 尝试为不同的分区找到不同的代理。 让我们看一个具有四个代理和两个分区且复制因子为三的示例：

 Broker 1 是分区 1 的领导者，代理 4 是分区 2 的领导者。因此，每个客户端在从这些分区发送或轮询消息时都会连接到这些代理。 为了获取有关分区领导者和其他可用代理（元数据）的信息，有一种特殊的引导机制。 总而言之，我们可以说每个代理都可以提供集群的元数据，因此客户端可以初始化与每个代理的连接，然后重定向到分区领导者。 这就是为什么我们可以指定多个代理作为引导服务器。

如果一个分区领导代理发生故障，Kafka 将声明仍在工作的代理之一作为新的分区领导者。 然后，所有客户端都必须连接到新的领导者。 在我们的示例中，如果 Broker 1 发生故障，Broker 2 将成为分区 1 的新领导者。然后，连接到 Broker 1 的客户端必须切换到 Broker 2。

Kafka 使用 Kraft（早期版本中：Zookeeper）来编排集群内的所有代理。

4.4 将所有内容汇总

如果我们将生产者和消费者与三个代理组成的集群放在一起，这些代理管理具有三个分区和复制因子 3 的单个主题，我们将得到以下架构：

5. 生态系统

5.1 Kafka连接API

Kafka Connect是一个用于与第三方系统交换数据的API。有现有的连接器，例如用于 AWS S3、JDBC，甚至用于在不同 Kafka 集群之间交换数据。当然，我们也可以编写自定义连接器。

5.2 Kafka流API

KSQL 是一个构建在 Kafka Streams 之上的类似 SQL 的接口。 它不需要我们开发Java代码，但我们可以声明类似SQL的语法来定义与Kafka交换的消息的流处理。 为此，我们使用连接到 Kafka 集群的 ksqlDB。 我们可以使用 CLI 或 Java 客户端应用程序访问 ksqlDB。

5.3 KSQL

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）
[外链图片转存中…(img-kV2ULO0E-1713272325787)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！