Kafka 相关核心概念

忘是亡心i 2023-10-10 12:23 125阅读 0赞

## kafaka 简介 ##

Apache Kafka  是一个快速、可扩展的、高吞吐的、可容错的分布式 “ 发布 \- 订阅 ” 消息系统， 使用 Scala  与  Java  语言编写，能够将消息从一个端点传递到另一个端点，较之传统的消息中间件（例如 ActiveMQ 、 RabbitMQ ）， Kafka  具有高吞吐量、内置分区、支持消息副本和高容 错的特性，非常适合大规模消息处理应用程序。

Kafka  官网： http://kafka.apache.org/

## kafaka 系统架构 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70][]

## kafaka 应用场景 ##

### 用户的活动追踪： ###

用户在网站的不同活动消息发布到不同的主题中心，然后可以对这些消息进行实时监测实时处理。当然，也可加载到 Hadoop 或离线处理数据仓库，对用户进行画像。像淘宝、京东这些大型的电商平台，用户的所有活动都是要进行追踪的。

### 日志聚合: ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 1][]

### 限流削峰: ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 2][]

## kafaka特性之高吞吐 ##

Kafka  与其它  MQ  相比，其最大的特点就是高吞吐率。为了增加存储能力， Kafka  将所有的消息都写入到了低速大容的硬盘。按理说，这将导致性能损失，但实际上，kafka  仍可保 持超高的吞吐率，性能并未受到影响。其主要采用了如下的方式实现了高吞吐率。

  顺序读写： Kafka  将消息写入到了分区  partition  中，而分区中消息是顺序读写的。顺序

读写要远快于随机读写。

  零拷贝：生产者、消费者对于  kafka  中消息的操作是采用零拷贝实现的。

  批量发送： Kafka  允许使用批量消息发送模式。

  消息压缩： Kafka  支持对消息集合进行压缩。

## kafaka 集群搭建(windows) ##

参考文章：[Windows 搭建Kafka 集群][Windows _Kafka]

## kafaka 专业术语 ##

### Topic（主题）： ###

主题。在 Kafka 中，使用一个类别属性来划分消息的所属类，划分消息的这个类称为 topic。topic 相当于消息的分类标签，是一个逻辑概念。

### Partition（分区）： ###

分区。topic 中的消息被分割为一个或多个 partition，其是一个物理概念，对应到系统上就是一个或若干个目录。partiiton 本身是一个 FIFO 队列，其中的消息是有序的。但在 Partition 间无法保证消息的顺序性。

### segment(段): ###

段。将 partition 进一步细分为了若干的 segment，每个 segment 文件的最大大小相等。

### Broker(中间件) ###

Kafka 集群包含一个或多个服务器，每个服务器节点称为一个 broker。  
假设某个 topic 中有 N 个 partition，集群中有 M 个 Broker，broker 与 partition 间的数量  
关系：  
若 N>=M，且（N%M=0），则每个 broker 上会平均存储 N/M 个 partition。  
若 N>M，且（N%M!=0），这其中会出现 broker 上分配的 partition 不平均的情况。这种情况要避免。  
若 N<M，这种情况会出现有的 broker 上没有分到 partition 的情况。

### Producer(生成者) ###

生产者。即消息的发布者，其会将某 topic 的消息发布到相应的 partition 中。

### Consumer(消费者) ###

消费者。可以从 broker 中读取消息。  
一个消费者可以消费多个 topic 的消息。  
一个消费者可以消费同一个 topic 中的多个 partition 消息。  
一个 partition 允许多个无关消费者同时消费。

### Consumer Group(消费组) ###

consumer group 是 kafka 提供的可扩展且具有容错性的消费者机制。组内可以有多个消费者，它们共享一个公共的 ID，即 group ID。组内的所有消费者会协调在一起平均消费订阅主题的所有分区。  
Kafka 可以保证在稳定状态下，一个 partition 中的消息只能被同一个 consumer group 中的一个 consumer 消费，而一个组内 consumer 只会消费某一个或几个特定的 partition。当然，一个消息可以同时被多个 consumer group 消费。

总结：  
组内 consumer 与 partition 的关系 1:n  
partition 与组内 consumer 的关系 1:1

这种设计方式的好处是：实现简单，弊端是：消息分配不均。

组中 consumer 数量与 partition 数量的对应关系如下。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 3][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 4][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 5][]

### Replicas of partition(分区副本) ###

分区副本。副本是一个分区的备份，是为了防止消息丢失而创建的分区的备份。

### Partition Leader(分区领导) ###

每个 partition 有多个副本，其中有且仅有一个作为 Leader，Leader 是当前负责消息读写的 partition。即所有读写操作只能发生于 Leader 分区上。

### Partition Follower(分区跟随者) ###

所有 Follower 都需要从 Leader 同步消息，Follower 与 Leader 始终保持消息同步。partition leader 与 follower 是主备关系，而非主从

### ISR ###

ISR ， In-Sync Replicas ，是指副本同步列表。

AR ， Assigned Replicas

OSR ， Outof-Sync Replicas

AR = ISR + ORS

### offset(偏移量) ###

偏移量。每条消息都有一个当前 Partition 下唯一的 64 字节的 offset，它是相对于当前分区第一条消息的偏移量

### offset commit(偏移量提交) ###

Consumer 从 partition 中取出一批消息写入到 buffer 对其进行消费，在规定时间内消费完消息后，会自动将其消费消息的 offset 提交给 broker，以让 broker 记录下哪些消息是消费过的。当然，若在时限内没有消费完毕，其是不会提交 offset 的。  
提交的 offset 被写入到了一个特殊的主题\_\_consumer\_offsets 中。  
其中在 kafka0.9 版本之前，offset 是由 zk 负责保存管理的，之后版本由 kafka broker 负责保 存管理。

### Rebalance(负载均衡) ###

当消费者组中消费者数量发生变化，或 Topic 中的 partition 数量发生了变化时，partition的所有权会在消费者间转移，即 partition 会重新分配，这个过程称为再均衡 Rebalance。  
再均衡能够给消费者组及 broker 集群带来高可用性和伸缩性，但在再均衡期间消费者是无法读取消息的，即整个 broker 集群有一小段时间是不可用的。因此要避免不必要的再均衡。

### HW 与 LEO ###

HW ， HighWatermark ，高水位，表示  Consumer  可以消费到的最高  partition  偏移量。 HW

保证了  Kafka  集群中消息的一致性。确切地说，是在  broker  集群正常运转的状态下，保证了

partition  的  Follower  与  Leader  间数据的一致性。

LEO ， Log End Offset ，日志最后消息的偏移量。消息是被写入到  Kafka  的日志文件中的，

这是当前最后一个写入的消息在  Partition  中的偏移量。

对于  leader  新写入的消息， consumer  是不能立刻消费的。 leader  会等待该消息被所有

ISR  中的  partition follower  同步后才会更新  HW ，此时消息才能被  consumer  消费。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 6][]

### Broker Controller(中间件控制层) ###

Kafka  集群的多个  broker  中，有一个会被选举为  controller ，负责管理整个集群中  partition

和副本  replicas  的状态。

当  partition leader  宕机后， broker controller  会从  ISR  中选举出一个  Follower  做为新的

leader 。所谓选举就是从  ISR  中找到第一个  Follower ，直接让其当选新的  leader 。

Broker Controller  是由  zk  选举出来的。

### Zookeeper ###

Zookeeper 负责维护和协调 broker，负责 Broker Controller 的选举。

### Coordinator(协调者) ###

Coordinator  一般指的是运行在每个  broker  上的  group Coordinator  进程，用于管理

Consumer Group  中的各个成员，主要用于  offset  位移管理和  Rebalance 。一个  Coordinator  可

以同时管理多个消费者组。

## kafaka 工作原理和过程 ##

### 消息路由策略 ###

在通过  API  方式发布消息时，生产者是以  Record  为消息进行发布的。 Record  中包含  key

与  value ， value  才是我们真正的消息本身，而  key  用于路由消息所要存放的  Partition 。消息

要写入到哪个  Partition  并不是随机的，而是有路由策略的。

1)  若指定了  partition ，则直接写入到指定的  partition ；

2)  若未指定  partition  但指定了  key ，则通过对  key  的  hash  值与  partition  数量取模，该取模

结果就是要选出的  partition  索引；

3)  若  partition  和  key  都未指定，则使用轮询算法选出一个  partition 。

### 消息写入算法 ###

消息生产者将消息发送给  broker ，并形成最终的可供消费者消费的  log ，是一个比较复

杂的过程。

1) producer  向  broker  集群提交连接请求，其所连接上的任意  broker  都会向其发送  broker

controller  的通信  URL ，即  broker controller  主机配置文件中的  listeners  地址

2)  当  producer  指定了要生产消息的  topic  后，其会向  broker controller  发送请求，请求当前

topic  中所有  partition  的  leader  列表地址

3) broker controller 在接收到请求后，会从 zk 中查找到指定 topic 的所有 partition 的 leader ，

并返回给  producer

4) producer  在接收到  leader  列表地址后，根据消息路由策略找到当前要发送消息所要发送

的  partition leader ，然后将消息发送给该  leader

5) leader  将消息写入本地  log ，并通知  ISR  中的  followers

6) ISR  中的  followers  从  leader  中同步消息后向  leader  发送  ACK

7) leader  收到所有  ISR  中的  followers  的  ACK  后，增加  HW ，表示消费者已经可以消费到该

位置了

### HW 截断机制 ###

如果  partition leader  接收到了新的消息，  ISR  中其它  Follower  正在同步过程中，还未同

步完毕时 leader 挂了。此时就需要选举出新的 leader 。若没有 HW 截断机制，将会导致 partition

中  leader  与  follower  数据的不一致。

### 消息发送的可靠性机制 ###

生产者向 kafka 发送消息时，可以选择需要的可靠性级别。通过 acks 参数的值进行设置。

**（** **1** **）**  **0**  **值**

异步发送。生产者向  kafka  发送消息而不需要  kafka  反馈成功  ack 。该方式效率最高，但

可靠性最低。其可能会存在消息丢失的情况。

**（** **2** **）**  **1**  **值**

同步发送，默认值。生产者发送消息给  kafka ， broker  的  partition leader  在收到消息后

马上发送成功  ack （无需等待  ISR  中的  follower  同步完成），生产者收到后知道消息发送成功，

然后会再发送消息。如果一直未收到  kafka  的  ack ，则生产者会认为消息发送失败，会重发

消息。

**（** **3** **）**  **-1**  **值**

同步发送。其值等同于  all 。生产者发送消息给  kafka ， kafka  收到消息后要等到  ISR  列表

中的所有副本都同步消息完成后，才向生产者发送成功  ack 。如果一直未收到  kafka  的  ack ，

则认为消息发送失败，会自动重发消息。

### 消费者消费过程解析 ###

生产者将消息发送到  topic  中，消费者即可对其进行消费，其消费过程如下：

1) consumer  向  broker  集群提交连接请求，其所连接上的任意  broker  都会向其发送  broker

controller  的通信  URL ，即  broker controller  主机配置文件中的  listeners  地址

2)  当  consumer  指定了要消费的  topic  后，其会向  broker controller  发送  poll  请求

3) broker controller  会为  consumer  分配一个或几个  partition leader ，并将该  partitioin  的当

前  offset  发送给  consumer

4) consumer  会按照  broker controller  分配的  partition  对其中的消息进行消费

5)  当消费者消费完该条消息后，消费者会向  broker  发送一个该消息已被消费的反馈，即

该消息的  offset

6)  当  broker  接到消费者的  offset  后，会更新到相应的 \_\_consumer\_offset  中

7)  以上过程一直重复，直到消费者停止请求消息

8)  消费者可以重置  offset ，从而可以灵活消费存储在  broker  上的消息

### Partition Leader 选举范围 ###

当  leader  挂了后  broker controller  会从  ISR  中选一个  follower  成为新的  leader 。但，若  ISR

中的所有副本都挂了怎么办？可以通过  unclean.leader.election.enable  的取值来设置  Leader

选举的范围。

**（** **1** **）**  **false**

必须等待 ISR 列表中有副本活过来才进行新的选举。该策略可靠性有保证，但可用性低。

**（** **2** **）**  **true**

在  ISR  中没有副本的情况下可以选择任何一个没有宕机主机中该  topic  的  partition  副本

作为新的  leader ，该策略可用性高，但可靠性没有保证。

### 重复消费问题及解决方案 ###

参考文章地址:[Kafka重复消费场景及解决方案][Kafka]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210118103124752.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/2021011810334131.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20210118103418617.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n,size_16,color_FFFFFF,t_70
[Windows _Kafka]: https://blog.csdn.net/zhouzhiwengang/article/details/112678302
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20210118105047487.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20210118105104730.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20210118105119227.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20210118115548199.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V6aGl3ZW5nYW5n,size_16,color_FFFFFF,t_70
[Kafka]: https://zhuanlan.zhihu.com/p/112745985