今天我要讲的是卡夫卡。我主要尝试重新理解Kafka，谈谈Kafka比较重要的概念和问题。在以后的文章中，我们将介绍：

Kafka 的一些高级功能，例如工作流。只需使用Docker 安装Kafka 并使用它来发送和消费消息即可。 Spring Boot 程序如何使用Kafka 作为消息队列。现在，当我们提到Kafka时，我们已经假设它是一个非常好的消息队列，并且我们经常将它与RocketMQ和RabbitMQ进行比较。我认为Kafka相对于其他消息队列的主要优点是：

性能优良：基于Scala和Java语言开发，设计大量采用批处理和异步思想，每秒可处理数千万条消息。无与伦比的生态系统兼容性：Kafka与周围生态系统的兼容性是最好的之一，尤其是在大数据和流计算领域。事实上，早期版本的Kafka在消息队列方面并不完善，存在一些小问题，比如消息丢失、没有消息可靠性保证等。当然，这与LinkedIn最初开发Kafka是为了处理大量日志有很大关系。哈哈，没想到后来竟然被用来当消息队列了。站错队了。

随着后续的发展，这些缺点逐渐被Kafka纠正和完善。因此，认为Kafka作为消息队列不可靠的观点已经过时了。

初识 Kafka

首先我们看一下官网的介绍，这应该是最权威、最实时的网站了。是英文还是非英文都没关系。我们已经提取了最重要的信息。

从官方介绍中可以得到以下信息：

Kafka 是一个去中心化的流媒体平台。这是什么意思？

流媒体平台具有三个重要特征。

消息队列：Kafka也被归类为消息队列，因为消息流的发布和订阅与消息队列类似。一种容错、持久化的存储和记录消息流的方式：Kafka将消息持久化到磁盘，有效避免消息丢失的风险。流处理平台：为了在消息发布时对其进行处理，Kafka提供了完整的流处理库。 Kafka主要有两个应用场景。

消息队列：构建实时流数据管道，以在系统或应用程序之间可靠地检索数据。数据处理：构建实时流数据处理程序来转换或处理数据流。关于Kafka有一些非常重要的概念。

Kafka 在主题中存储记录流（流数据）。每条记录由键、值和时间戳组成。

Kafka 消息模型

旁注：早期的JMS 和AMQP 是消息服务领域的领先组织创建的相关标准，并在JavaGuide 《消息队列其实很简单》 文章中进行了介绍。然而这些标准的演变跟不上消息队列的演变，事实上这些标准已经退役了。因此，不同的消息队列有可能有自己的一套消息模型。

队列模型：早期的消息模型

使用队列作为满足生产者和消费者模型的消息通信载体。一条消息仅由一个消费者使用，并保留在队列中，直到被消费或超时。 示例：如果一个生产者发送100 条消息，两个消费者消费它们，通常这两个消费者将按照消息发送的顺序各消费一半消息（也就是说，如果你发送一条，我消费一条）。

队列模型的问题：

假设有一种情况，需要将生产者生产的消息分发给多个消费者，并且每个消费者都可以接收到完整的消息内容。

这种情况下队列模型就很难解决了。许多老练的人说：你可以为每个消费者创建一个单独的队列，并让生产者发送多个副本。这是一种非常愚蠢的做法，不仅浪费资源，而且违背了使用消息队列的目的。

发布-订阅模型：Kafka 消息模型

发布/订阅模型主要是为了解决队列模型的问题。

发布/订阅模型（Pub-Sub）与广播模型一样，使用主题作为消息通信的载体。发布者发布一条消息，通过主题分发给所有订阅者，消息发送后再分发给订阅的用户。无法接收广播消息。

当只有一个订阅者时，发布/订阅模型本质上与队列模型相同。因此，发布/订阅模型在功能层面上与队列模型是兼容的。

Kafka 使用发布/订阅模型。

RocketMQ的消息模型本质上和Kafka的消息模型是一样的。唯一的区别是RocketMQ没有队列的概念；相当于分区的概念。

Kafka 重要概念解读

如下图所示，Kafka将生产者发布的消息发送到主题，需要这些消息的消费者可以订阅这些主题。

Kafka主题分区

上图还介绍了Kafka的一些重要概念。

生产者：生产消息的一方。消费者：消费消息的一方。 Broker：可以认为是一个独立的Kafka实例。多个Kafka Broker组成一个Kafka集群。同时，你一定注意到了，每个broker都包含两个重要的概念：主题和分区。

主题：生产者向特定主题发送消息，消费者通过订阅特定主题来消费消息。分区：分区是主题的一部分。一个topic可以包含多个partition，同一个topic内的partition可以分布到不同的broker上。也就是说，主题可以跨越多个代理。这和上面画的图是一样的。要点：Kafka中的分区实际上可以对应于消息队列中的队列。这更有意义吗？

另外，我认为比较重要的一点是，Kafka引入了分区的多副本机制。 Partition 中的副本中，有一个副本称为Leader，其他副本称为Follower。你发送的消息会发送到leader副本，follower副本可以从leader副本中检索消息进行同步。

生产者和消费者仅与领导者副本交互。据了解，其他副本只是leader副本的简单副本，其存在只是为了保证消息存储安全。如果leader复制失败，则会从follower中选出一个leader，但如果有follower与leader不同步，则无法参与leader选举。

Kafka的多分区、多副本机制有什么好处？

Kafka可以通过为给定主题指定多个分区来提供更好的并发性（负载均衡），并且每个分区可以分布到不同的broker。一个分区可以指定对应的副本数量。这大大提高了消息存储的安全性和容灾能力，但也需要相应增加存储空间。

ZooKeeper 在 Kafka 中的作用

如果想了解ZooKeeper在Kafka中的作用，可以自己搭建一个Kafka环境，自己访问ZooKeeper来了解哪些文件夹与Kafka相关，每个节点上存储了哪些信息，需要查看是否是。 不要忽视练习。否则，你最终会忘记你所学到的东西。

下面的文章将向您展示如何搭建Kafka环境。别担心，看完下面的文章，3分钟就能搭建好Kafka环境。

本文内容引用并引用了这篇文章：https://www.jianshu.com/p/a036405f989c

下图显示了本地Zookeeper。已成功关联本地Kafka（以下文件夹结构是使用Idea插件ZooKeeper工具实现的）。

ZooKeeper主要为Kafka提供元数据管理功能。

从这张图中可以看出Zookeeper主要为Kafka做以下事情：

Broker注册：Zookeeper有一个节点专门用于记录Broker服务器列表。当每个代理启动时，它都会向Zookeeper 注册。这意味着它将在/brokers/ids下创建自己的节点。每个broker都会在节点上记录自己的IP地址、端口等信息，用于主题注册。 Kafka将同一主题的消息拆分为多个分区，并将这些分区中的信息和对应关系分发给多个broker。该代理也由Zookeeper 维护。例如，我创建了一个名为my-topic 的主题。相应地，在zookeeper中创建文件夹/brokers/topics/my-topic/partions/0和/brokers/topics/my-topic /partions。 /1 负载均衡：前面提到，Kafka可以通过为给定的topic指定多个分区来提供更好的并发性，并且每个分区可以分布到不同的broker上。对于同一主题的不同分区，Kafka 尽力将这些分区分布到不同的Broker 服务器上。当生产者生产消息时，它会尽力将消息分发到不同的代理分区。当Consumer消费时，Zookeeper可以根据当前分区数量和Consumer数量实现动态负载均衡。

Kafka 如何保证消息的消费顺序？

在使用消息队列时，经常会有需要保证严格的消息消费顺序的业务场景。比如有一个操作同时发送两条消息，对应这两条。消息对应于数据库操作。 是：更改用户会员级别，并根据会员级别计算订单价格。如果这两条消息以不同的顺序被消费，最终的结果将会完全不同。

我们知道Kafka分区是消息实际存储的地方，也是我们发送的消息将被放置的地方。分区存在于主题的概念中，可以为特定主题指定多个分区。

Kafka主题分区布局

每次将消息附加到分区时，都会使用尾部附加，如上图所示。 Kafka只能保证分区内消息的顺序，但不能保证主题内分区的顺序。

消息在添加到分区时会被分配一个特定的偏移量。 Kafka 使用偏移量来保证分区内消息的排序。

所以有一个非常简单的方法来保证消息消费的顺序。一个主题只对应一个分区。虽然这确实解决了问题，但却违背了Kafka设计的初衷。

使用Kafka发送消息时，可以指定四个参数：topic、partition、key、data。如果发送消息时指定分区，则所有消息都会发送到指定分区。此外，您可以确保具有相同密钥的消息仅发送到同一分区。为此，您可以使用表/对象的ID 作为键。

综上所述，Kafka中有两种方式保证消息消费顺序。

每个主题仅对应一个分区。 （推荐）发送消息时指定密钥/分区。当然，以上两种方法并不是唯一的。我觉得上面两种方法比较容易理解。