【Kafka】Kafka基础架构及相关概念_kafka消费完数据就没有了吗

前言

在以前的定义中，Kafka被定义为一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域，类似的产品主要有ActiveMQ、RabbitMQ、RocketMQ…，当然我们知道kafka的作用远不止用于消息队列，Kafka作为消息队列主要是基于点对点模式和基于发布订阅模式，其中，点对点模式表现为：消费者主动拉取数据，消息收到后清除消息。而发布订阅表现为：

• 可以有多个topic主题（浏览、点赞、收藏、评论等）。
• 消费者消费数据之后，不删除数据。
• 每个消费者相互独立，都可以消费到数据。

消息队列的主要应用场景包括：缓存/消峰、解耦和异步通信。
缓冲/消峰：有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。

解耦：允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

异步通信：允许用户把一个消息放入队列，但并不立即处理它，然后在需要的时候再去处理它们。

下面就介绍下Kafka中基本的概念知识…

一、Kafka基础知识

我们先来看下Kafka的基础架构：

从上图中我们可以看到，一个典型的Kafka体系架构包括若干Producer、若干Broker、若干Consumer以及一个ZooKeeper集群。其中ZooKeeper是Kafka用来负责集群元数据的管理、控制器的选举等操作的。Producer将消息发送到Broker，Broker负责将收到的消息存储到磁盘中，而Consumer负责从Broker订阅并消费消息。Kafka中的消息以主题为单位进行归类，生产者负责将消息发送到特定的主题，而消费者负责订阅主题并进行消费。

主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于单个主题。同一主题下的不同分区包含的消息是不同的，分区在存储层面可以看作一个可追加的日志文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量（offset）。offset是消息在分区中的唯一标识，Kafka通过它来保证消息在分区内的顺序性，不过offset并不跨越分区，也就是说，Kafka保证的是分区有序而不是主题有序。

注意：上图也只是Kafka的基础架构图，不一定能准确描Kafka各版本的改动信息，例如，在Kafka3.0+版本中，Kafka不再依赖于ZooKeeper管理元数据信息等。

Kafka分为服务器端和客户端。服务器端的元数据通常是指集群的元数据，包括集群有哪些Broker，有哪些主题，每个主题都有哪些分区，而每个分区的Leader副本在哪台Broker上等信息。这些信息保存在ZooKeeper和Controller中。Kafka以ZooKeeper中保存的元数据为权威数据，Controller会从ZooKeeper中获取最新的元数据并缓存在自己的内存中。客户端的元数据通常是指消费者的注册信息和位移信息。在Kafka 0.9版本之前，这些信息的确保存在ZooKeeper中。不过目前已经废弃了。新版本的消费者把这些信息保存在一个Kafka的内部主题中，由集群中一个名为Coordinator的组件进行管理。Kafka3.0以前（主要是指服务器端）是依赖ZooKeeper才能正常运转的。3.0后移除对ZooKeeper的依赖。具体的原理是在Kafka内部实现一个基于Raft的Controller集群，来替代ZooKeeper保存和管理集群元数据。

下面将解释Kafka中的各种基础概念：

• Producer：消息生产者，就是向 Kafka Broker 发消息的客户
• Consumer：消息消费者，向 Kafka Broker 取消息的客户端。
• Consumer Group（CG）：消费者组，由多个 Consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
• Broker：一台 Kafka 服务器就是一个 Broker 。一个集群由多个 Broker 组成。一个Broker 可以容纳多个 Topic。
• Topic：可以理解为一个队列，生产者和消费者面向的都是一个 Topic。
• Partition：为了实现扩展性，一个非常大的 Topic可以分布到多个 Broker （即服务器）上，一个 Topic可以分为多个 Partition，每个 Partition是一个有序的队列。
• Replica：副本。一个 Topic的每个分区都有若干个副本，一个 Leader 和若干个Follower。
• Leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 Leader。
• Follower：每个分区多个副本中的“从”，实时从 Leader 中同步数据，保持和Leader 数据的同步。Leader 发生故障时，某个 Follower 会成为新的Leader。
  Controller：由zookeeper选举其中一个Broker产生。它的主要作用是在ZooKeeper 的帮助下管理和协调整个 Kafka 集群。
  Message：每⼀条发送的消息主体。
  Offset：消费者消费的位置信息，监控数据消费到什么位置，当消费者挂掉再重新恢复的时候，可以从消费位置继续消费。
  High Level API 和Low Level API ：高水平API，Kafka本身定义的行为，屏蔽细节管理，使用方便；低水平API细节需要自己处理，较为灵活但是复杂。
  HW（High Watermark）：俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取这个offset之前的消息。
  LEO（Log End Offset）：它标识当前日志文件中下一条待写入消息的offset。
• Coordinator：也叫”协调者“，专门为 Consumer Group 服务，负责Group Rebalance 以及提供位移管理、组成员管理等。Consumer 端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker 提交位移。同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送各种请求，然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。

当所有 Broker 在启动时，都会创建和开启相应的 Coordinator 组件。也就是说，所有 Broker 都有各自的 Coordinator 组件。不同的group id会被哈希到不同的分区上，从而不同的Broker 能充当不同group的Coordinator。

二、Kafka分区副本

当Kafka生产者给Kafka集群（多个Broker组成Kafka集群）发送消息时，会根据分区规则选择存储到Broker中的哪个具体的分区。如果分区规则设定得合理，所有的消息都可以被均匀地分配到不同的分区中。

Kafka为分区引入了多副本机制，通过增加副本数量可以提升容灾能力。同一分区的不同副本中保存的是相同的消息，副本之间是一主多从的关系，其中Leader副本负责处理读写请求，Follower副本只负责与Leader副本的消息同步。副本处于不同的Broker中，当Leader副本出现故障时，从Follower副本中重新选举新的Leader副本对外提供服务。Kafka通过多副本机制实现了故障的自动转移，当Kafka集群中某个Broker失效时仍然能保证服务可用。

Consumer使用拉模式从服务端拉取消息，并且保存消费的具体位置，当消费者宕机后恢复上线时可以根据之前保存的消费位置重新拉取需要的消息进行消费，这样就不会造成消息丢失。

在Kafka中，分区中的所有副本统称为AR。所有与Leader副本保持一定程度同步的副本（包括Leader副本在内）组成ISR，ISR集合是AR集合中的一个子集。消息会先发送到Leader副本，然后Follower副本才能从Leader副本中拉取消息进行同步，同步期间内Follower副本相当于Leader副本而言会有一定程度的滞后。与Leader副本同步滞后过多的副本（不包括Leader副本）组成OSR，AR=ISR+OSR，在正常情况下，所有的Follower副本都应该与Leader副本保持一定程度的同步，即AR=ISR，OSR集合为空。

Leader副本负责维护和跟踪ISR集合中所有Follower副本的滞后状态，当Follower副本落后太多或失效时，Leader副本会把它从ISR集合中剔除。如果OSR集合中有Follower副本追上了Leader副本，那么Leader副本会把它从OSR集合转移至ISR集合。默认情况下，当Leader副本发生故障时，只有在ISR集合中的副本才有资格被选举为新的Leader，而在OSR集合中的副本则没有任何机会。

参考

1、Kafka基本概念、集群搭建、生产者与消费者
2、【尚硅谷】2022版Kafka3.x教程（从入门到调优，深入全面）