如果你刚接触Kafka，你一定会对各种概念感到困惑。让我们整理一下高级学习Kafka 所需了解的概念。

这篇博客也可以作为进一步了解Kafka的初步资料。

什么是Kafka

Kafka基于Scala和Java语言开发，大量运用了批处理和异步思想。这是一个用于构建实时数据管道和流的应用程序。

Kafka的应用场景

Kafka是一个分布式流处理平台。流媒体平台具有三个重要特征。

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

消息队列：构建实时流数据管道，以在系统或应用程序之间可靠地检索数据。数据处理：构建实时流数据处理程序来转换或处理数据流。

注：2.8预览版中，Kafka采用Raft元数据模式，消除了对Zookeeper的依赖。

Kafka的版本里程碑

版本号

状态

0.8

引入复制机制，实现真正完整、分布式、可靠的消息队列解决方案

0.8.2

新版本生产者API，生产者需要指定broker地址

0.9

添加了基本的安全认证/权限，并用Java重写了新版本的消费者API

0.10

介绍卡夫卡流

0.11

它提供了幂等生产者API和事务性API，并重构了Kafka消息格式。

1.0

对Kafka 流的各种改进

2.0

对Kafka 流的各种改进

Kafka的优势

高吞吐量和低延迟：这是一个显着的特性，可以让Kafka 实现百万级别的消息吞吐量和低至毫秒的延迟。持久化存储：Kafka消息最终持久化在磁盘上，通过Kafka的复制机制提供顺序读写来保证性能并提高数据可靠性。分布式可扩展性：Kafka的数据按主题组织，按分区分布。整体的可扩展性非常好。高容错性：如果集群中任意一个broker节点宕机，Kafka可以继续对外提供服务。

Kafka基本结构

Kafka 有四个核心API。

Producer API：将消息发布到一个或多个主题。 Consumer API：订阅一个或多个主题并处理生成的消息。 Stream API：充当流处理器，使用来自一个或多个主题的输入流并向一个或多个输出主题生成输出流，从而有效地将输入流转换为输出流。连接器API：构建或运行可重用的生产者或消费者，以将主题连接到现有应用程序或数据系统。例如，关系数据库的连接器可以捕获对表的所有更改。

Kafka的关键术语

生产者：消息和数据生产者，向Kafka 主题发布消息的流程/代码/服务。 Consumer：消息和数据的消费者，订阅数据（主题）并处理已发布消息的流程/代码/服务。消费者群体：同一主题广播给不同的群体。在一个组中，一条消息只能供该消费者组中的一个消费者使用。消费者组不能包含比分区更多的消费者。否则，其他消费者将不必要地等待并且不会收到消息。

主题：发布到Kafka 集群的每条消息都有一个类别，称为主题。它的作用是区分和分离数据。 Broker：Kafka集群中的每个Kafka节点。保存主题的一个或多个分区。分区：一个物理概念，Kafka中数据存储的基本单位。主题数据分布在多个分区中存储。每个分区都是一个连续的、不可变的消息队列，可以不断地向其中添加消息。

笔记：

每个主题的信息分为多个分区。将分区数设置为1可以保证消息消费的顺序。如果一个topic有N个partition，一个集群有N个broker，每个broker存储该topic的一个partition。如果一个topic有N个partition，一个集群有(N+M)个broker，那么N个broker存储该topic的分区，其余M个broker不存储该topic的分区数据。如果一个topic有N个分区，且集群中的broker数量小于N，则一个broker存储该topic的一个或多个分区。在实际生产环境中，请尽量避免这种情况，因为它很容易导致Kafka集群中的数据不平衡。当代理收到消息时，它会根据分区算法选择一个分区来存储消息。路由机制根据指定的分区来确定路由的优先级。如果未指定分区但指定了键，则如果既未指定分区也未指定键，则通过散列键的值来选择分区。通过轮询选择分区。

Offset：偏移量，消息在Kafka自己维护的分区内的位置。消费者还必须存储偏移量以维护正在消费的消息的位置。复制：同一个分区可以有多个副本，副本之间的数据相同，提高容错性和可扩展性。笔记：

如果集群中某个broker挂掉了，系统可以主动使用复制来提供服务。默认情况下，系统将每个主题的复制因子设置为1。这可以在创建主题时单独设置。复制的基本单位是主题分区。所有读写均由leader执行，follower仅作为数据的备份。追随者必须能够及时复制领导者的数据。

复制领导者：对于一个分区的多个副本，领导者必须与该分区上的生产者和消费者进行交互。一个分区仅对应一个复制领导者。复制追随者：追随者跟随领导者，所有写请求都会广播给所有追随者，追随者和领导者保持数据同步。 ReplicaManager：负责管理当前broker的所有分区和副本信息，处理KafkaController发起的多个请求，切换副本状态，添加/读取消息等。重新平衡。当消费者组中的一个消费者实例终止时，其他消费者实例会自动重新分配订阅主题分区。再平衡是Kafka消费者实现高可用的重要手段。

Kafka 使用Zookeeper 来管理集群配置、选举领导者并在消费者组发生变化时执行重新平衡。

Kafka的复制机制

如何将所有Replication均匀分布到整个集群

为了实现更好的负载平衡，Kafka 尝试将所有分区均匀分布在集群中。典型的部署是主题分区的数量大于代理的数量。同时，同一分区的复制应尽可能分布在不同的机器上，以提高Kafka的容错能力。如果所有复制都在同一个Broker 上，那么如果Broker 宕机，该分区的所有复制将不再能够运行，并且不会产生HA 效果。同时，如果某个代理发生故障，我们需要确保该代理上的负载均匀分布在所有其他幸存代理上。

Kafka分配复制的算法是：

对所有代理（假设总共有n 个代理）和分配的分区进行排序。将第i 个分区分配给第(i % n) 个代理。将第i 个分区的第j 个复制分配给第((i + j) % n) 个代理。

HW高水位与LEO

HW代表High Watermark，俗称高水位线，消费者只能检索到这个偏移量之前的消息。

如图所示，该日志文件有九条消息，第一条消息的偏移量（LogStartOffset）为8，最后一条消息的偏移量为9。虚线框代表要写入的下一条消息。日志文件HW 为6。这意味着消费者只能获取偏移量0-5处的消息，而偏移量6处的消息对消费者来说是不可见的。

LEO 代表Log End Offset，表示写入当前日志文件的下一条消息的偏移量。图中偏移9 处的位置对应于当前日志文件的LEO。当前日志分区的最后一条消息。偏移值增加1。分区ISR集中的每个副本都维护自己的LEO，ISR集中最小的LEO是分区的HW。消费者只能在HW之前消费消息。

ISR副本集合

ISR的全称是“同步副本”。这是分区内与领导副本同步的复制列表。正常情况下，ISR 应包含阅读器的副本。

ISR列表在Zookeeper中维护，ISR列表中的副本可以参与Leader选举。

ISR 列表动态变化。副本包含在ISR 列表中的条件由replica.lag.time.max.ms 参数控制。该参数的含义是副本同步延迟的最大时间间隔。默认值为10 秒。这意味着，由于JVM FullGC等问题，follower所在的broker被排除在ISR之外，相对于leader的滞后大于10秒。 Kafka这样设计主要是为了减少消息丢失。只有与leader副本实时同步的follower副本才能参与leader选举。

笔记：

分区内的所有副本统称为分配副本(AR)。 ISR 集是AR 集的子集。与主副本（不包括主副本）同步太慢的副本会形成不同步副本（OSR）

复制机制

如图所示，假设某个分区的ISR 集具有三个副本：一个主副本和两个跟随副本。在本例中，分区的LEO 和HW 均为3。当生产者发送消息3 和4 时，它们首先存储在读取器副本中。

消息写入Leader副本后，Follower副本发送拉取请求拉取消息3和4进行消息同步。

在同步过程中，不同follower副本的同步效率也不同。某一时刻，follower 1 完全追上了leader副本，而follower 2只同步了消息3。在这种情况下，领导者副本的LEO 为5，追随者1 的LEO 为5，追随者2 的LEO 为4。在这种情况下，当前分区的HW取最小值4，所以此时消费者可以消费偏移量为0到3的消息。

如果所有副本都成功写入消息3和消息4，则整个分区的HW和LEO将为5，因此消费者可以在偏移量4处消费该消息。

关于读写分离

Kafka 不支持读/写分区。生产端和消费者端的所有读/写请求均由复制主副本处理。复制跟随者副本的主要工作是从领导者副本异步拉取和同步消息。不对外提供消息数据读写服务。

Kafka这样设计主要是为了保证读写的一致性。这是因为如果追随者副本未与领导者完全同步，您可能无法从追随者副本中读取数据。最新消息。

Kafka的消息发送机制

Producer 使用推送模式向Broker 发布消息。这是顺序写入磁盘（顺序写入磁盘比随机写入内存更高效，保证了kafka的吞吐量）。

生产者创建如下所示的消息序列图。

aoimg.com/pgc-image/5c7465db61c4438b989091ac0a034cb7~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1717774721&x-signature=pB6mY3YVJ%2Btb6ItWsE0aKfvlCFg%3D” alt=”5c7465db61c4438b989091ac0a034cb7~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1717774721&x-signature=pB6mY3YVJ%2Btb6ItWsE0aKfvlCFg%3D” />
流程说明：
Producer先从Zookeeper的”/brokers/…/state”节点找到该Partition的Leader。Producer将消息发送给该Leader。Leader将消息写入本地log。followers从Leader pull消息，写入本地log后Leader发送ACK。Leader收到所有ISR中的replica的ACK后，增加HW并向Producer发送ACK。

Broker保存消息

每个patition物理上对应一个文件夹（该文件夹存储该patition的所有消息和索引文件）
无论消息是否被消费，Kafka都会保留所有消息。有两种策略可以删除旧数据：
基于时间：log.retention.hours=168基于大小：log.retention.bytes=1073741824

Consumer消费消息

Kafka集群保持所有的消息，直到它们过期（无论消息是否被消费）。实际上消费者所持有的仅有的元数据就是这个offset（偏移量），也就是说offset由消费者来控制：正常情况当消费者消费消息的时候，偏移量也线性的的增加。但是实际偏移量由消费者控制，消费者可以将偏移量重置为更早的位置，重新读取消息。可以看到这种设计对消费者来说操作自如，一个消费者的操作不会影响其它消费者对此log的处理。

参考：
一文看懂大数据领域的六年巨变：https://www.infoq.cn/article/b8*EMm6AeiHDfI3SfT11https://kafka.apache.org/documentation/https://stackoverflow.com/questions/tagged/apache-kafka?sort=newest&pageSize=15《Kafka权威指南》