Kafka 源码剖析：消息存储与协议实现（一）

一、引言

**

在当今大数据与分布式系统盛行的时代，消息队列作为重要的中间件，承担着数据异步传输、系统解耦以及流量削峰等关键任务 。Kafka，作为消息队列领域的佼佼者，以其卓越的高吞吐量、可扩展性和可靠性，被广泛应用于各种大规模数据处理和实时流计算场景中，如日志收集、用户行为追踪、金融交易数据处理等。无论是互联网巨头公司，还是新兴的创业企业，Kafka 都成为了构建其数据基础设施的重要组成部分。

深入了解 Kafka 的内部机制，尤其是消息存储与协议实现原理，对于开发者和运维人员来说至关重要。通过研究源码，我们能够洞察 Kafka 是如何在高并发、海量数据的环境下高效稳定运行的，从而在实际应用中，更加得心应手地进行性能优化、故障排查以及系统架构设计。例如，在处理海量日志数据时，如果能够深入理解 Kafka 的消息存储机制，就可以合理配置存储参数，提高存储效率和数据读取速度；在分布式系统中，了解 Kafka 的协议实现，可以更好地进行系统间的通信协调，确保数据的准确传输和系统的高可用性。接下来，让我们一起深入到 Kafka 的源码世界，揭开其消息存储与协议实现的神秘面纱。

二、Kafka 源码环境搭建

2.1 版本选择

在进行 Kafka 源码分析时，选择合适的版本至关重要。当前 Kafka 的版本不断迭代更新，每个版本都带来了新特性、性能优化以及 Bug 修复 。经过综合考量，我们选择 Kafka 2.7.0 版本作为本次源码分析的目标版本。这是因为从 2.8.0 版本开始，Kafka 去掉了对 Zookeeper 的依赖，这一变化虽然代表着 Kafka 架构的重大演进，但在生产环境中还不够稳定。而 2.7.0 版本在稳定性和功能特性上达到了较好的平衡，既包含了 Kafka 在消息存储、协议实现等方面的成熟机制，又没有引入过于激进的架构变动，非常适合作为深入学习 Kafka 内部原理的切入点。

2.2 所需环境准备

搭建 Kafka 源码环境，需要准备以下工具及对应的版本：

• JDK：选用 1.8 版本。Java Development Kit（JDK）是 Kafka 运行的基础，1.8 版本具有广泛的兼容性和稳定性，被众多开源项目所采用，能为 Kafka 的编译和运行提供良好的支持。许多 Kafka 的核心功能，如多线程处理、网络通信等，都依赖于 JDK 1.8 提供的特性和库。

• Scala：采用 2.12 版本。由于 Kafka Broker 端源码是基于 Scala 编写的，Scala 语言的简洁性、高效性以及对函数式编程的支持，使得 Kafka 的代码结构更加紧凑和灵活。2.12 版本与 Kafka 2.7.0 版本具有良好的兼容性，能确保在编译和运行 Kafka 源码时不会出现版本不匹配的问题。

• Gradle：选择 6.6 版本。Gradle 是一种基于 Groovy 的项目自动化构建工具，它在 Kafka 项目中负责管理项目依赖、编译代码、运行测试等任务。6.6 版本能够很好地满足 Kafka 2.7.0 版本的构建需求，其强大的依赖管理功能可以自动下载和管理 Kafka 所需的各种依赖库，大大简化了项目的构建过程。

• Zookeeper：使用 3.4.14 版本。Zookeeper 在 Kafka 中扮演着重要的角色，它负责管理 Kafka 集群的元数据信息，如 Broker 节点的注册、Topic 的创建和删除、Partition 的分配等。3.4.14 版本是一个稳定的版本，被广泛应用于 Kafka 集群的部署中，为 Kafka 集群的高可用性和一致性提供了可靠的保障。

2.3 搭建步骤详解

1. JDK 安装与配置：

• • 下载 JDK 1.8 安装包，可从 Oracle 官方网站获取。

• • 运行安装程序，按照提示完成安装过程，安装路径可选择默认路径或自定义路径。

• • 配置环境变量，在系统环境变量中添加JAVA_HOME，其值为 JDK 的安装目录，例如C:\Program Files\Java\jdk1.8.0_xxx。然后在Path变量中添加%JAVA_HOME%\bin和%JAVA_HOME%\jre\bin，确保系统能够找到 Java 命令。

• • 验证安装，打开命令提示符，输入java -version，如果显示 JDK 的版本信息，则说明安装成功。

1. Scala 安装与配置：

• • 从 Scala 官方网站下载 2.12 版本的 Scala 安装包，根据操作系统选择对应的安装文件。

• • 解压安装包到指定目录，例如C:\scala-2.12.x。

• • 配置环境变量，在系统环境变量中添加SCALA_HOME，其值为 Scala 的解压目录。然后在Path变量中添加%SCALA_HOME%\bin。

• • 验证安装，打开命令提示符，输入scala -version，若显示 Scala 的版本信息，则表示安装成功。

1. Gradle 安装与配置：

• • 前往 Gradle 官网下载 6.6 版本的 Gradle 安装包，选择gradle-6.6-bin.zip文件。

• • 解压下载的压缩包到本地目录，如C:\gradle-6.6。

• • 配置环境变量，在系统环境变量中添加GRADLE_HOME，其值为 Gradle 的解压目录。然后在Path变量中添加%GRADLE_HOME%\bin。

• • 验证安装，打开命令提示符，输入gradle -v，如果显示 Gradle 的版本信息，则说明安装配置成功。

1. Zookeeper 安装与配置：

• • 从 Apache Zookeeper 官方网站下载 3.4.14 版本的安装包，文件名为apache-zookeeper-3.4.14.tar.gz。

• • 解压安装包到指定目录，如C:\zookeeper-3.4.14。

• • 进入解压后的conf目录，将zoo_sample.cfg文件复制一份并改名为zoo.cfg。

• • 根据需要修改zoo.cfg中的配置，例如可以修改dataDir参数指定数据存储目录，默认情况下dataDir指向zookeeper-3.4.14\data目录，如果该目录不存在，需要手动创建。另外，还可以根据实际情况配置clientPort参数指定客户端连接端口，默认为 2181。

• • 启动 Zookeeper 服务，进入zookeeper-3.4.14\bin目录，执行zkServer.cmd（Windows 系统）或zkServer.sh start（Linux 系统）启动 Zookeeper 服务。可以通过查看日志文件zookeeper.out（位于zookeeper-3.4.14\logs目录下）来确认服务是否启动成功，如果日志中没有报错信息，并且出现类似于binding to port 0.0.0.0/0.0.0.0:2181的信息，则表示 Zookeeper 服务已成功启动。

1. Kafka 源码下载与构建：

• • 从 Kafka 官方网站下载 2.7.0 版本的源码包，也可以从 GitHub 上克隆 Kafka 的仓库。

• • 解压源码包到本地目录，例如C:\kafka-2.7.0-src。

• • 进入 Kafka 源码目录，打开build.gradle文件，由于默认的镜像源下载速度可能较慢，我们可以将其更换为国内的镜像源，比如阿里云的镜像源。在buildscript和allprojects的repositories中添加如下配置：

buildscript {

repositories {

maven { url 'https://maven.aliyun.com/nexus/content/groups/public/' }

maven { url 'https://maven.aliyun.com/nexus/content/repositories/jcenter' }

}

}

allprojects {

repositories {

maven { url 'https://maven.aliyun.com/nexus/content/groups/public/' }

maven { url 'https://maven.aliyun.com/nexus/content/repositories/jcenter' }

}

}

• 使用 Gradle 构建 Kafka 源码项目，在命令提示符中进入 Kafka 源码目录，执行./gradlew idea（Linux 系统）或gradlew idea（Windows 系统）命令，该命令会下载 Kafka 项目所需的各种依赖库，并生成 IDEA 项目文件。构建过程可能需要一些时间，具体取决于网络速度和机器性能。在构建过程中，如果出现依赖下载失败的情况，可以尝试手动下载依赖库并放置到对应的目录中，或者检查网络连接是否正常，以及镜像源配置是否正确。

1. 导入到 IDE：

• • 打开 IntelliJ IDEA（或其他支持 Gradle 项目的 IDE），选择File -> Open，然后选择 Kafka 源码目录下的build.gradle文件，IDEA 会自动识别并导入 Kafka 项目。

• • 导入完成后，等待 IDEA 加载项目依赖和索引文件，这个过程可能也需要一些时间。加载完成后，就可以在 IDE 中浏览和分析 Kafka 的源码了。在浏览源码时，可以使用 IDE 提供的代码导航、代码分析等功能，方便快速定位和理解 Kafka 的核心代码逻辑。例如，可以使用Ctrl + N（Windows/Linux）或Command + O（Mac）快捷键快速查找类和方法，使用Ctrl + Shift + F（Windows/Linux）或Command + Shift + F（Mac）快捷键进行全局搜索等。

通过以上步骤，我们就成功搭建了 Kafka 2.7.0 版本的源码环境，为后续深入分析 Kafka 的消息存储与协议实现原理奠定了基础。

三、消息存储机制深度剖析

3.1 物理存储结构概览

Kafka 通过文件的方式保存所有的 topic 数据，更确切地说，是保存分区副本 。在 Kafka 的 broker 配置中，有一个关键参数log.dirs，它指定了若干个逗号分隔的目录，例如/first/kafka-logs,/second/kafka-logs,/third/kafka-logs 。这些目录用于存储 Kafka 的消息数据，需要注意的是，不要将其与 Kafka 自身运行输出的日志目录混淆，Kafka 运行日志的存储位置定义在log4j.properties文件中。当 Kafka 接收到生产者发送的消息时，会根据 topic 和分区信息，将消息存储到log.dirs指定目录下对应的分区文件中。这种基于文件的存储方式，为 Kafka 实现高吞吐量和持久化存储提供了基础。

3.2 分区分配策略

3.2.1 无机架信息时的分配

在创建一个 topic 时，我们会指定分区数和副本数，此时 Kafka 需要决定这些副本应该分布在哪些 broker 上。其分配目标主要有两个：一是均匀分布，尽量让每个 broker 上的副本数目一样多，这样可以充分利用集群资源，避免单个 broker 负载过高；二是保证高可用，尽量将同一分区的多个副本分配到不同的 broker 上，以防止某个 broker 故障导致整个分区不可用。

具体的分配过程如下：假设我们有 6 台 broker，ID 分别为 0，1，2，3，4，5，现在要创建一个 3 分区、3 副本的 topic。首先，按照分区顺序一个一个来分配。对于分区 0 的 leader 副本，Kafka 会为它随机选择一个 broker，假设选择了 broker 3，那么分区 0 的第一个副本（即 leader 副本）存储在 broker 3，为了保证高可用，第二个副本存储在 broker 4，第三个副本存储在 broker 5。接着分配分区 1，由于分区 0 的 leader 在 broker 3 上，为了实现均匀分配和高可用，分区 1 的 leader 副本会存储在 broker 4，然后两个 follower 副本分别存储在 broker 5 和 broker 0。最后分配分区 2，其 leader 副本存储在 broker 5，两个 follower 副本分别存储在 broker 0 和 broker 1 。通过这样的分配方式，既保证了副本在各个 broker 上的均匀分布，又确保了同一分区的多个副本分布在不同的 broker 上，提高了系统的容错性和可用性。

3.2.2 有机架信息时的分配

当 broker 配置了机架信息，即设置了broker.rack参数（这是一个字符串，用来配置每台 broker 所在的机架名称）后，分区分配策略在基本分配方式不变的基础上，会对 broker 的排列方式进行调整 。目的是尽可能将每个分区的副本分配到不同的机架，以防一个机架出现故障（如掉电、断网等）造成整个分区的下线。

同样假设现在有两个机架，6 台 broker，还是要分配一个 3 分区、3 副本的 topic。在分配时，首先会在逻辑上对 broker 进行排列，尽量让每个 broker 和不同机架的 broker 相邻。因为同一分区的不同副本都是分配给相邻的 broker，这样做就可以保证副本会分布在不同机架上。例如，在实际分配过程中，会优先将副本分配到不同机架的 broker 上，确保在机架层面实现高可用。这种分配策略在大规模分布式集群中，尤其是存在多个机架的环境下，能够有效提高系统的可靠性和稳定性，避免因单个机架故障而导致数据丢失或分区不可用的情况发生。为分区副本选择 broker 的工作是由 controller 完成的，controller 会根据集群的状态信息和配置参数，按照上述策略进行合理的分区分配。

3.3 文件管理机制

3.3.1 分区目录结构

每个分区的数据都存储在一个单独的目录下，目录命名规则为topic名-分区数 。例如，对于test-topic这个 topic 的第 0 个分区，其目录名称就是test-topic-0 。在这个目录下，存储着该分区的所有数据。这种以 topic 和分区为维度的目录结构，使得 Kafka 在管理和查找数据时更加方便高效。当需要读取或写入某个分区的数据时，Kafka 可以直接根据目录名快速定位到对应的目录，然后进行相应的操作。而且，这种结构也便于对不同 topic 和分区的数据进行独立的管理和维护，比如可以对不同分区设置不同的存储策略、清理策略等。

3.3.2 segment 文件管理

分区数据并不是存储在一个文件里，而是分布在多个 segment 文件中。这是因为 Kafka 作为一个消息队列，数据是有过期时间的，数据过期之后需要被删除。如果将所有数据存储在一个大文件中，根据时间或大小判断数据过期并删除时，操作会非常耗时并且容易出错。而采用将每个分区的数据存储在多个 segment 文件中的方式，以 segment 作为数据过期的基本单位，当某个 segment 文件过期时，直接把它删除即可，大大提高了数据管理的效率和可靠性。

segment 文件有活跃和关闭两种状态 。正在写入数据的 segment 处于活跃状态，活跃状态的 segment 文件不会被删除，以保证数据写入的连续性和完整性。当一个 segment 文件达到一定的大小或者有一段时间没有写入数据时，它就会被关闭 。关闭的大小和时间分别由log.segment.bytes和log.segment.ms这两个参数控制 。默认只设置了大小，值为 1G，即当一个 segment 文件大小达到 1G 时，就会被关闭。当两个参数都设置时，只要有一个条件满足，这个 segment 文件就会被关闭 。例如，如果同时设置了log.segment.bytes为 1G 和log.segment.ms为 3600000（即 1 小时），那么当一个 segment 文件大小达到 1G 或者距离上次写入数据的时间超过 1 小时，该 segment 文件就会被关闭。需要注意的是，broker 对每个 segment 文件都持有一个文件句柄，即使是关闭的 segment 文件，所以在实际应用中需要小心调节操作系统的文件句柄相关参数，避免出现文件句柄耗尽等问题。

3.4 文件格式解析

在每个 segment 文件里，存储了消息和对应的 offset，并且存储的格式和生产者向 broker 生产以及消费者从 broker 消费时的消息格式是一样的 。这种一致性保证了 broker 向消费者发送消息时可以使用 "零拷贝" 技术，避免了数据的重复拷贝和额外的编解码操作，大大提高了数据传输的效率，同时也避免了数据的压缩与解压（因为生产者发送的就是压缩过后的消息） 。

每条消息除了包含消息的 key、value 和 offset 之外，还包含以下重要字段：消息大小，用于记录消息的字节数，方便在存储和传输过程中进行数据量的统计和控制；校验码，用于验证消息在传输和存储过程中的完整性，确保消息没有被篡改或损坏；消息格式的版本，随着 Kafka 的不断发展和演进，消息格式也可能会发生变化，通过版本字段可以标识消息所采用的格式版本，以便在处理消息时进行正确的解析和操作；压缩格式，当生产者发送压缩的消息时，这里会记录消息的压缩格式，如 GZIP、Snappy 或 LZ4 等，消费者在消费消息时可以根据压缩格式进行解压缩；时间戳，时间戳可以是生产者发送时的时间戳（由log.message.timestamp.type参数决定，当该参数值为CreateTime时），也可以是 broker 接收时的时间戳（当log.message.timestamp.type参数值为LogAppendTime时） 。在实际应用中，这些字段协同工作，为 Kafka 实现高效、可靠的消息存储和传输提供了保障。例如，通过 offset 可以快速定位消息在 segment 文件中的位置，校验码可以确保消息的准确性，时间戳可以用于实现消息的过期清理、按时间顺序处理等功能。

3.5 索引文件机制

为了支持消费者从任意指定的 offset 开始消费，Kafka 需要能够快速定位消息，为此它为每个 segment 文件建立了索引文件 。索引文件采用稀疏索引的方式，不会为每条消息都创建索引，而是根据log.index.interval.bytes等配置构建稀疏索引信息 。这样做的好处是可以大大减少索引文件的大小，降低存储开销。虽然查找时可能需要消耗更多的时间，但通过合理的配置和优化，可以在存储和查询性能之间找到平衡。

具体来说，索引文件中包含多个索引条目，每个条目表示数据文件中一条 Message 的索引 。索引包含两个部分（均为 4 个字节的数字），分别为相对 offset 和 position 。相对 offset 是指消息在当前 segment 文件中的相对偏移量，position 则表示该消息在 log 文件中的物理偏移地址 。例如，当消费者需要查找某个 offset 对应的消息时，Kafka 首先会根据 offset 找到对应的 segment 文件，然后在该 segment 文件的索引文件中，通过二分查找找到最接近目标 offset 的索引条目 。由于是稀疏索引，找到的索引条目对应的 offset 可能小于目标 offset，此时 Kafka 会根据索引条目中的 position 信息，从 log 文件的相应位置开始顺序扫描，直到找到目标 offset 对应的消息 。通过这种方式，Kafka 在保证高效存储的同时，实现了对消息的快速定位和查询。

3.6 通过 offset 查找 message 的过程

结合实例来看，假设我们要读取 offset=368776 的 message，需要通过以下两个主要步骤进行查找：

1. 查找 segment file：每个 segment 文件的命名规则是以上一个 segment 文件最后一条消息的 offset 值命名。例如，00000000000000000000.index表示最开始的文件，其起始偏移量 (offset) 为 0 。第二个文件00000000000000368769.index的消息量起始偏移量为 368770（即 368769 + 1） 。同样，第三个文件00000000000000737337.index的起始偏移量为 737338（即 737337 + 1），其他后续文件依次类推 。只要根据 offset 二分查找文件列表，就可以快速定位到具体文件 。当 offset=368776 时，通过二分查找可以定位到00000000000000368769.index|log这个 segment 文件 。

1. 通过 segment file 查找 message：通过第一步定位到 segment 文件后，当 offset=368776 时，首先在00000000000000368769.index索引文件中，通过二分查找找到最接近 368776 的索引条目 。假设找到的索引条目中相对 offset 为 368770，position 为 497 。这意味着从 log 文件的 497 位置开始，可能存储着我们要找的消息 。然后从00000000000000368769.log文件的 497 位置开始顺序查找，直到找到 offset=368776 的消息为止 。在实际查找过程中，由于索引文件采用稀疏索引，可能需要在 log 文件中进行一定范围的顺序扫描，但通过这种先定位 segment 文件，再利用索引文件和 log 文件配合查找的方式，能够在海量消息存储的情况下，快速准确地找到指定 offset 对应的 message 。