Kafka简介

kafka简介：

Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

口头说法：kafka就是消息传递系统 将需要使用消息的服务作为消费组 将产生消息的服务作为生产者 本身也能存在若干个消息存储

个人疑问：

• 什么是消息？
• 哪些服务需要这些消息？
• 怎么拉取和存放消息？
• 和zookeeper如何配合？

解答：

第一个问题：什么是消息？

 

kafka里面的消息就是apache kafka中传输的数据单元。由两部分 键 和 值 组成

键（Key）：键是一个可选项，它用于标识要发送的消息。如果提供了键，则 Kafka 将根据键使用哈希函数将消息路由到特定的分区中。如果未提供键，则会随机选择一个分区。

值（Value）：值是消息的主体内容，可以是任何类型的二进制数据。

也就是用键来标识对应的值 多个消息被组织成topic（美其名曰主题）

 

第二个问题： 消息是如何存放的？

 

kafka消息是通过分布式存储的方式进行持久化存储的 每个主题被分为多个分区 每个分区都有自己的一个或者多个副本 kafka的消息其实是被写入到分区中 保存到一个或者多个日志片段文件里（重点）

Kafka 将消息以追加方式写入到日志片段文件（Log Segment File）中。当一个日志片段文件大小达到预先配置的阈值（问题来了：如何设置阈值？有什么影响？后续补上）时，它将会被关闭并且不再接受新的消息，同时一个新的日志片段文件将被创建用于存储后续的消息。当所有的副本都确认了消息已经被写入到磁盘时，生产者才认为消息发送成功。

总的来说，Kafka 的消息存放位置可以简单地概括为：主题 -> 分区 -> 日志片段文件。

 

第三个问题：如何拉取消息：

 

消费者从特定的分区中读取消息，每个消费者维护自己的消费偏移量（Consumer Offset）-（问题来了：在那哪里记录？什么形式记录？）来记录已经读取的消息位置。消费者可以按照任何顺序读取消息，并且可以在任何时间停止和重新开始消费。如果一个消费者组内的某个消费者故障退出，则其余的消费者将会重新平衡分区，以确保每个分区都被恰好一个消费者处理。

 第四个补充问题： 消息文件的类型

 

 kafka的消息文件的类型：

通过公司文档发现 kafka消息存放在kafkalogs目录（不要被log迷惑 就是消息 不是目录）

索引文件：（index File） 每个日志片段文件都有一个对应的索引文件 用来快速查找消息 用" .index ” 为后缀名，并且存储着消息偏移量和物理位置的映射关系

位置索引文件：（offset index File）：每个分区都有一个位移索引文件 用于记录消费者/组的消费偏移量信息。用 “ .timeindex” 为后缀， 并且包含了时间戳二号物理位置之间的关系。

被删除文件：（Delete File）：当消息过期或者删除时，kafka会将其标记 并写入到删除文件中，以“ .delete ”为后缀

文件锁（File Lock）： 在进行读写操作时，kafka会使用文件锁确保线程安全性 以“.lock”为后缀 通常时空文件

快照（Snapshot）： 一种用于备份和恢复kafka消息的文件格式 覆盖面是很广的 比如快照存储文件就是存储了一个主题下所有分区的消费偏移量和消息检查点信息。进行消费组恢复时可以使用这个快照快速恢复消费组状态。还有一个快照索引文件 记录了分区的起始位置信息。 注意：两种快照恢复时主题和分区不能发生变化

 

最后一个问题：如何和zk打配合？ 为什么和zk打配合？

Kafka 在2.8.0 版本之前完全依赖 ZooKeeper（简称 ZK）实现分布式协调，ZK 是 Kafka 集群的 “大脑中枢”；2.8.0 版本后推出了 KRaft 模式（Kafka Raft），可替代 ZK 实现元数据管理，但传统架构中 ZK 与 Kafka 的搭配仍是核心知识点。

总结起来： 

ZK 核心特性	具体含义	对 Kafka 的价值
树形 ZNode 目录结构	数据以类似文件系统的树形节点（ZNode）存储，分为持久节点/临时节点/有序节点	为 Kafka 的元数据提供结构化存储（如按 broker、topic、consumer 分组存储）
临时节点（Ephemeral ZNode）	节点与客户端会话绑定，会话失效（如进程宕机、网络断开）则节点自动删除	实现 Kafka 的故障检测（如 Broker 宕机后自动注销）
Watcher 监听机制	客户端可监听 ZNode 的变化（创建 / 删除 / 数据修改），变化时 ZK 主动推送通知	让 Kafka 组件（Producer/Consumer/Broker）实时感知集群状态变化（如新增 Broker、主题分区变化）
ZAB 一致性协议	保证 ZK 集群中所有节点的数据一致（主从复制 + 崩溃恢复）	确保 Kafka 的元数据在分布式环境下不丢失、不冲突
有序节点（Sequential ZNode）	创建节点时 ZK 自动为节点添加递增序号（如 /leader/0000000001）	实现 Kafka 的选主逻辑（如 Controller 节点选举）

Kafka 与 ZooKeeper 搭配的核心原理：数据存储与交互逻辑

Kafka 将非业务数据（元数据） 全部存储在 ZK 中，而业务数据（消息） 存储在本地磁盘（日志文件）中。简单来说：ZK 是 Kafka 的 “元数据中心”，Kafka 通过操作 ZK 的 ZNode 实现分布式协调。

Kafka 如何利用 ZK 的特性工作

Kafka 的各个组件（Broker、Producer、Consumer）启动后，会与 ZK 建立会话，通过创建 / 读取 / 监听 ZNode实现协同工作，核心逻辑如下：

1. 注册与发现：Broker 启动时，在/brokers/ids/{broker.id}创建临时节点，并写入自身的地址、端口等信息；Producer/Consumer 通过读取/brokers/ids节点，获取所有在线 Broker 的列表，实现集群发现。
2. 故障检测：若 Broker 宕机，与 ZK 的会话断开，/brokers/ids/{broker.id}临时节点被自动删除；Producer/Consumer 通过监听该节点，实时感知 Broker 下线，从而切换到其他 Broker 进行生产 / 消费。
3. 选主逻辑：Kafka 的 Controller 节点（集群的管理节点）选举，通过在/controller节点创建临时有序节点实现 —— 第一个创建节点的 Broker 成为 Controller，其他 Broker 监听该节点，若 Controller 宕机，节点删除，触发重新选举。
4. 事件通知：当 Topic 被创建 / 删除、分区副本被重新分配时，ZK 的对应 ZNode 发生变化，监听该节点的 Broker/Producer/Consumer 会收到通知，从而更新本地缓存的元数据，无需轮询。

1. Kafka 集群启动流程

1. 所有 Broker 启动，向 ZK 的/brokers/ids创建临时节点，注册自身信息。
2. 所有 Broker 尝试创建 ZK 的/controller节点，第一个成功的 Broker 成为 Controller。
3. Controller 读取 ZK 中所有 Topic 的元数据，为每个分区分配 leader 副本，并将状态写入 ZK。
4. Producer 连接 ZK，读取/brokers/ids和 Topic 元数据，确定生产消息的 Broker 和分区。
5. Consumer 连接 ZK，读取 Broker 列表和 Topic 元数据，加入消费组并获取分区分配。

2. 消费者消费流程

1. 消费者启动，连接 ZK，读取/brokers/ids获取在线 Broker 列表。
2. 消费者加入消费组，在 ZK 的/consumers/{groupName}/ids创建临时节点。
3. 消费组协调者为消费者分配分区，消费者向对应 Broker 的分区发起消费请求。
4. 消费者消费消息后，将 offset 写入 ZK 的/consumers/{groupName}/offsets节点。
5. 若消费者宕机，ZK 节点删除，协调者重新分配分区，其他消费者接管消费。

• 特性：

Kafka https://kafka.apache.org/

• 是一种高吞吐量(https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines)的分布式发布订阅（https://baike.baidu.com/item/%E5%8F%91%E5%B8%83%E8%AE%A2%E9%98%85/22695073?fromModule=lemma_inlink）消息系统，有如下特性：
• 通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
• 高吞吐量 ：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。
• 支持通过Kafka服务器和消费机集群来分区消息。
• 支持Hadoop并行数据加载

相关术语：

• "Broker" Kafka集群包含一个或多个服务器，这种服务器被称为broker
• "Topic" 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）
• "Partition" Partition是物理上的概念，每个Topic包含一个或多个Partition.
• "Producer" 负责发布消息到Kafka broker
• "Consumer" 消息消费者，向Kafka broker读取消息的客户端。
• "Consumer Group" 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。