当前位置： 首页>后端>正文

Kafka知识点梳理

后端2024-04-24 23:37:08

1.kafka基本概念

1.1 安装kafka

docker安装kafka(单机版)

docker安装kafka(Kraft集群版)

1.2 项目背景

Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。

1.3 kafka可以做什么

  • 发布和订阅事件流，包括从其他系统持续导入/导出数据。
  • 持久可靠地存储事件流
  • 实时或回顾性地处理事件流

1.5 kafka架构示意图1: zookeeper版本

Kafka知识点梳理,第1张
kafka架构示意图.png

一个典型的Kafka 体系架构包括:

  • 若干 Producer(消息生产者)
  • 若干 Broker(作为Kafka节点的服务器)
  • 若干 Consumer(Group)
  • 一个 ZooKeeper 集群

Kafka 通过 ZooKeeper 管理集群配置、选举 Leader 以及在 consumer group 发生变化时进行 Rebalance (即消费者负载均衡).

Producer 使用 push(推) 模式将消息发布到 broker, Consumer 使用 pull(拉) 模式从 broker 订阅并消费消息.

Kafka知识点梳理,第2张
kafka架构示意图2.png

2. kafka中的术语

Zookeeper

Kafka通过Zookeeper来存储集群的meta data(元数据) 、管理集群配置、选举leader、负载均衡等.

问题: zookeeper是什么

ZooKeeper 是一个分布式的、开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现。分布式应用程序可以基于它实现统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等工作

问题: zookeeper的作用

broker 注册、topic 注册、producer 和 consumer 负载均衡、维护 partition 与 consumer 的关系、记录消息消费的进度以及 consumer 注册等

Broker

Kafka集群中的服务实例, 也称之为节点, 一个Broker就是一个服务器或节点, 每个Kafka集群包含一个或多个Broker.

Topic

消息的类别, 主要用于对消息进行逻辑上的区分

  • 每条发送到Kafka集群的消息都需要有一个指定的Topic
  • 消费者根据Topic对指定的消息进行消费
  • 多订阅者模式,一个topic可以拥有一个或多个消费者来订阅它的数据

Partition

每一个 Topic 又被分为多个 Partitions，即物理分区；出于负载均衡的考虑，同一个 Topic 的 Partitions 分别存储于 Kafka 集群的多个 broker 上；而为了提高可靠性，这些 Partitions 可以由 Kafka 机制中的 replicas 来设置备份的数量

Kafka知识点梳理,第3张
kafka分区示意图.png

Replica

partition 的副本，副本的数量是可以配置的

Kafka知识点梳理,第4张
kafka副本示意图.png

Kafka 定义了两类副本:

Leader Replica, 对外提供服务, producer 和 consumer 只跟 leader 交互

Follower Replica, 被动跟随

Segment

一个partition当中存在多个segment文件段(分段存储)

问题: 为什么不能以partition作为存储单位

当 Kafka producer 不断发送消息，必然会引起 partition 文件的无限扩张，将对消息文件的维护以及已消费的消息的清理带来严重的影响，因此，需以 segment 为单位将 partition 进一步细分。每个 partition（目录）相当于一个巨型文件被平均分配到多个大小相等的 segment（段）数据文件中（每个 segment 文件中消息数量不一定相等）这种特性也方便 old segment 的删除，即方便已被消费的消息的清理，提高磁盘的利用率。每个 partition 只需要支持顺序读写就行，segment 的文件生命周期由服务端配置参数（log.segment.bytes，log.roll.{ms,hours} 等若干参数）决定。

问题: segment工作原理是怎样的

segment 文件由两部分组成，分别为 “.index” 文件和 “.log” 文件，分别表示为 segment 索引文件和数据文件。这两个文件的命令规则为：partition 全局的第一个 segment 从 0 开始，后续每个 segment 文件名为上一个 segment 文件最后一条消息的 offset 值，数值大小为 64 位，20 位数字字符长度，没有数字用 0 填充，如下：

00000000000000000000.index
00000000000000000000.log
00000000000000170410.index
00000000000000170410.log
00000000000000239430.index
00000000000000239430.log

以上面的 segment 文件为例，展示出 segment：00000000000000170410 的 “.index” 文件和 “.log” 文件的对应的关系，如下图：

Kafka知识点梳理,第5张
kafka-segment示意图.png

如上图，“.index” 索引文件存储大量的元数据，“.log” 数据文件存储大量的消息，索引文件中的元数据指向对应数据文件中 message 的物理偏移地址。其中以 “.index” 索引文件中的元数据 [3, 348] 为例，在 “.log” 数据文件表示第 3 个消息，即在全局 partition 中表示 170410+3=170413 个消息，该消息的物理偏移地址为 348。

问题: 如何在partition中通过offset查找message

以上图为例，读取 offset=170418 的消息，首先查找 segment 文件，其中 00000000000000000000.index 为最开始的文件，第二个文件为 00000000000000170410.index（起始偏移为 170410+1=170411），而第三个文件为 00000000000000239430.index（起始偏移为 239430+1=239431），所以这个 offset=170418 就落到了第二个文件之中。其它后续文件可以依次类推，以其偏移量命名并排列这些文件，然后根据二分查找法就可以快速定位到具体文件位置。其次根据 00000000000000170410.index 文件中的 [8,1325] 定位到 00000000000000170410.log 文件中的 1325 的位置进行读取。

要是读取 offset=170418 的消息，从 00000000000000170410.log 文件中的 1325 的位置进行读取，那么，如何确定何时读完本条消息呢？（否则就读到下一条消息的内容了）

这个问题由消息的物理结构解决，消息都具有固定的物理结构，包括：offset（8 Bytes）、消息体的大小（4 Bytes）、crc32（4 Bytes）、magic（1 Byte）、attributes（1 Byte）、key length（4 Bytes）、key（K Bytes）、payload（N Bytes）等等字段，可以确定一条消息的大小，即读取到哪里截止。

Message

  • 通过Kafka集群进行传递的对象实体,存储需要传递的消息

Record

  • 实际写入 Kafka 中并可以被读取的消息记录。每个 record 包含了 key、value 和 timestamp

Producer

消息的生产者,负责往Kafka集群中发送消息

Consumer

  • 消息的消费者,主动从Kafka集群中拉取消息
  • Kafka 有消费组的概念，每个消费者只能消费所分配到的分区的消息，每一个分区只能被一个消费组中的一个消费者所消费，所以同一个消费组中消费者的数量如果超过了分区的数量，将会出现有些消费者分配不到消费的分区
  • 消费者数量应小于Topic的分区数

Consumer Group

  • 每个Consumer属于一个特定的Consumer Group,新建Consumer的时候需要指定对应的Consumer Group ID
  • 群组可以保证每个分区只被这个群组里的一个消费者读取

Consumer Offset

偏移量（Consumer Offset）是一种元数据，它是一个不断递增的整数值，用来记录消费者发生重平衡时的位置，以便用来恢复数据

Kafka知识点梳理,第6张
kafka消费者消费消息.png

Rebalance

  • 重平衡:消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段

Acks

默认值：0，0 表示 producer 毋须等待 leader 的确认，1 代表需要 leader 确认写入它的本地 log 并立即确认，-1 代表所有的备份都完成后确认。只对 async 模式起作用，这个参数的调整是数据不丢失和发送效率的 tradeoff，如果对数据丢失不敏感而在乎效率的场景可以考虑设置为 0，这样可以大大提高 producer 发送数据的效率主题 1

3. Kafka特性

高吞吐,低延迟

kakfa 最大的特点就是收发消息非常快，kafka 每秒可以处理几十万条消息，它的最低延迟只有几毫秒

高伸缩性

每个主题(topic) 包含多个分区(partition)，主题中的分区可以分布在不同的主机(broker)中

持久性,可靠性

Kafka 能够允许数据的持久化存储，消息被持久化到磁盘，并支持数据备份防止数据丢失，Kafka 底层的数据存储是基于 Zookeeper 存储的，Zookeeper的数据能够持久存储

容错性

允许集群中的节点失败，某个节点宕机，Kafka 集群能够正常工作

高并发

支持数千个客户端同时读写

4. kafka使用场景

活动跟踪

Kafka 可以用来跟踪用户行为，比如我们经常会去淘宝购物，你打开淘宝的那一刻，你的登陆信息，登陆次数都会作为消息传输到 Kafka ，当你浏览购物的时候，你的浏览信息，你的搜索指数，你的购物爱好都会作为一个个消息传递给 Kafka ，这样就可以生成报告，可以做智能推荐，购买喜好等

传递消息

Kafka 另外一个基本用途是传递消息，应用程序向用户发送通知就是通过传递消息来实现的，这些应用组件可以生成消息，而不需要关心消息的格式，也不需要关心消息是如何发送的。

度量指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告

日志记录

Kafka 的基本概念来源于提交日志，比如我们可以把数据库的更新发送到 Kafka 上，用来记录数据库的更新时间，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等

流式处理

流式处理是有一个能够提供多种应用程序的领域

限流削峰

Kafka 多用于互联网领域某一时刻请求特别多的情况下，可以把请求写入Kafka 中，避免直接请求后端程序导致服务崩溃

5. kafka核心API

Producer API

它允许应用程序向一个或多个 topics 上发送消息记录

Consumer API

允许应用程序订阅一个或多个 topics 并处理为其生成的记录流

Streams API

它允许应用程序作为流处理器，从一个或多个主题中消费输入流并为其生成输出流，有效的将输入流转换为输出流

Connector API

它允许构建和运行将 Kafka 主题连接到现有应用程序或数据系统的可用生产者和消费者。例如，关系数据库的连接器可能会捕获对表的所有更改

6. Kafka为何快

零拷贝

Kafka 实现了零拷贝原理来快速移动数据，避免了内核之间的切换

顺序读写

Kafka 采取顺序写入磁盘的方式，避免了随机磁盘寻址的浪费

分批发送

Kafka 可以将数据记录分批发送，从生产者到文件系统（Kafka 主题日志）到消费者，可以端到端的查看这些批次的数据

消息压缩

批处理能够进行更有效的数据压缩并减少 I/O 延迟

文章参考
https://juejin.cn/post/6844903495670169607
https://zhuanlan.zhihu.com/p/389939447
https://gitbook.cn/books/5ae1e77197c22f130e67ec4e/index.html


https://www.xamrdz.com/backend/3cc1933660.html

相关文章：