Apache Kafka 诞生于对海量实时日志流处理的迫切需求，其设计目标是应对每天千亿级规模的日志数据吞吐。这种规模的数据流具有两个显著特征：

。 数据以持续不断的方式涌入，要求系统能够实时处理；同时，庞大的数据量也对存储和处理能力提出了极高的要求。 因此，Kafka 的架构必须有效应对分布式系统常见的“三高”挑战：

Kafka 的存储子系统需要满足以下要求：

Kafka 的存储设计需要在读写性能之间取得平衡。由于处理的是海量数据流，单纯追求高性能读写是不现实的。磁盘的顺序 I/O 性能显著优于内存的随机 I/O 性能，因此 Kafka 的存储策略充分利用了这一特性。

为了提高读取速度，索引技术是常用的手段。 索引允许快速定位特定消息，显著降低读取延迟。但是，索引的维护会增加写入操作的开销，降低写入速度。 关系型数据库（如 MySQL）便是索引技术的典型应用，但其读写性能平衡更偏向于读。

为了提高写入速度，Kafka 采用基于日志的顺序追加写入方式。这种方式避免了随机 I/O 操作，极大提升了写入效率。 数据以顺序的方式追加到日志文件中，无需维护复杂的索引结构。 这种方法的缺点是读取速度较慢，需要顺序扫描日志文件才能找到目标消息，效率较低。 许多大数据系统（例如 Hadoop 的 HDFS）都采用了类似的日志存储方式，将写入性能置于优先地位。

Kafka 的存储设计巧妙地结合了这两种方式的优势。它利用顺序写入保证高吞吐量，同时通过分段日志和稀疏索引等机制，在一定程度上提升了读取性能，最终实现高效的读写平衡，满足海量实时数据流的存储需求。 这种设计使得 Kafka 能够在处理高吞吐量写入的同时，提供相对高效的数据读取能力。

Kafka 作为一种强大的流处理平台，主要设计用来高效处理海量数据流。其应用场景具有以下几个特征：

在面对极高的写入效率需求时，Kafka 采用

，成功满足百万TPS的写入目标。然而，核心挑战在于如何实现对这些日志的高效查询。为此，Kafka 引入了稀疏哈希索引（底层基于哈希表实现）的方法。

在设计中，Kafka 将每条消息的 Offset 定义为有序字段，这意味着消息在日志文件中也按序存放，无需引入额外的哈希表结构。系统将消息分割为多个块，并为每个块索引第一条消息的 Offset。这一设计类似于二分查找的原理：首先根据 Offset 的大小快速找到相应的块，然后在块内顺序查找，最终高效定位到所需的消息。

在 Kafka 中，一个 Topic 对应多个 Partition，而每个 Partition 进一步划分为多个 Segment，每个 Segment 下则包含多个文件，主要包括“

为了防止生产者源源不断地产生消息导致 log 文件过大，从而降低数据定位的效率，Kafka 采取了分片与索引的机制，将每个 Partition 分为多个 Segment。每个 Segment 由两个主要文件组成：“

” 数据文件，这些文件都会存储在同一目录下，以便于管理。文件夹的命名规则遵循主题名加分区号的格式。例如，对于主题“test”拥有三个分区，其对应的文件夹为 test-0，test-1 和 test-2。

$ ls /tmp/kafka-logs/test-0
00000000000000000000.index  00000000000000000000.log  00000000000000000000.timeindex  leader-epoch-checkpoint

在这里，index 和 log 文件的命名使用当前 Segment 的第一条消息的 Offset。下图展示了 index 文件与 log 文件的结构示意。

” 文件用于存储大量的索引信息，而“

” 文件则负责存储大量的数据。索引文件中的元数据指向数据文件中对应消息的物理偏移量。

要查看索引信息，可以使用如下命令：

sh ./kafka-dump-log.sh --files /tmp/kafka-logs/test-0/00000000000000000000.index

Dumping /tmp/kafka-logs/test-0/00000000000000000000.index
offset: 19999 position: 300695
Mismatches in :/tmp/kafka-logs/test-0/00000000000000000000.index
  Index offset: 19999, log offset: 10000

/tmp/kafka-logs/test-0/
├── 00000000000000000000.index
├── 00000000000000000000.log
├── 00000000000000000000.timeindex
└── leader-epoch-checkpoint

这种存储架构使Kafka在保证高吞吐量的同时，实现了高效的消息检索能力，完美平衡了写入性能和查询效率的需求。

Kafka 的存储实现方案最终归结为：

顺序追加写日志 + 稀疏哈希索引

。其架构设计围绕着「主题（Topic） + 分区（Partition） + 副本（Replica） + 分段（Segment） + 索引（Index）」的结构展开：

Kafka 将消息按主题（Topic）进行分类，每个主题在逻辑上是独立的。每个 Topic 可以细分为一个或多个分区（Partition），在发送消息时会根据既定的分区规则将其追加到指定的分区。

每个 Log 目录对应一个以 Topic 名称为基础命名的文件夹。例如，假设存在一个名为“topic-order”的 Topic，该 Topic 包含四个 Partition。在物理存储中，分别会生成四个文件夹： "topic-order-0"、"topic-order-1"、"topic-order-2" 和 "topic-order-3"。

在 Kafka 中，消息的写入操作是顺序进行的。然而，只有最后一个 Log Segment 才能够执行写入操作，之前的所有 Log Segment 均无法进行写入。为了更好地理解这一概念，我们将最后一个 Log Segment 称为"active Segment"，它是当前活跃的日志分段。随着消息的不断写入，当 active Segment 达到一定条件时，就会创建一个新的 active Segment，以便后续追加的消息能够写入新的分段。

为了提升消息检索的效率，每个 Log Segment 中的日志文件（后缀为“.log”）都会对应几个索引文件，包括偏移量索引文件（后缀为“.index”）、时间戳索引文件（后缀为“.timeindex”）以及可能存在的快照索引文件（后缀为“.snapshot”）。每个 Log Segment 都有一个基准偏移量（baseOffset），用于表示该 Segment 中第一条消息的偏移量。偏移量以 64 位长整型数表示，日志文件和索引文件的命名均以基准偏移量为基础。例如，第一个 Log Segment 的基准偏移量为 0，相关的日志文件将命名为 00000000000000000000.log。

除了“.log”、“.index”、“.timeindex”这些主要文件外，每个 Log Segment 还可能包含“.snapshot”、“.txnindex”、“leader-epoch-checkpoint”等文件，以及 “.deleted”、“.cleaned”、“.swap”等临时文件。此外，在 Kafka 中，消费者在消费消息时，会将提交的位移记录保存在 Kafka 内部的主题 __consumer_offsets 中。

Kafka 的设计依赖于文件系统来存储和缓存消息，并采用典型的顺序追加写日志操作。它还利用操作系统的 Page Cache 来减少磁盘 I/O 操作，即将磁盘中的数据缓存到内存中，从而将对磁盘的访问转化为对内存的访问。

在 Kafka 中，Page Cache 的广泛应用是其能够实现高吞吐量的重要因素之一。当进程准备读取磁盘上的文件内容时，操作系统会先检查所需数据页是否在 Page Cache 中。如果命中，则直接返回数据以避免磁盘 I/O 操作；如果未命中，操作系统会向磁盘发起读取请求，并将读取的数据页存入 Page Cache，然后再将数据返回给进程。同样地，当进程需要将数据写入磁盘时，操作系统首先会检查该数据页是否存在于 Page Cache 中，若不存在，则将相应数据页添加至 Page Cache，最终再将数据写入到对应的数据页。被修改过的数据页会变成脏页，操作系统会在适当时机将这些脏页中的数据写入磁盘，以确保数据的一致性。

除了上述顺序追加写日志和 Page Cache 的技术外，Kafka 还采用了零拷贝（Zero-Copy）技术，以进一步提升系统性能。这种技术使得在读取和写入数据时，能够在内存与磁盘之间高效地传输数据，减少不必要的内存拷贝操作，从而优化了整体系统的性能。

Kafka 的架构设计中包含了几个核心角色：

在 Kafka 的工作流程中，生产者通过推送（push）的方式将消息发送到 Broker 中，Broker 接收到消息后进行存储，随后消费者以拉取（pull）的模式从 Broker 中订阅和消费这些消息。

保证生产者可靠性的关键在于确认机制，即在发送消息后是否能收到确认（ack）以及消息一旦收到确认后是否能确保不会丢失。Kafka 提供了多种配置选项来定义生产者在发送消息时应使用的 ack 策略：

6.1.1 Kafka 配置为 CP（Consistency & Partition tolerance）系统

当设置为提高一致性和分区容忍性时，可以使用如下参数：

request.required.acks = -1
min.insync.replicas = ${N/2 + 1}
unclean.leader.election.enable = false

 是集群中从属副本（follower）的数量。

在正常情况下，当所有的从属副本完成复制后，领导者（leader）将向生产者发送确认。当出现异常情况时，如果消息已发送到领导者，但某些副本（如 f1 和 f2）还在同步，而且领导者出现故障，那么任何一个从属副本都有可能被选为新的领导者。生产者此时会收到异常返回并重新发送数据，这可能导致数据重复（不过不会丢失）。

 参数用于确保当前集群中处于正常同步状态的从属副本数量。若实际值小于配置值，集群将停止服务。配置为 

，即超过一半的数量，能保证在满足此条件下系统的强一致性，而在不满足的情况下则会牺牲可用性。

 控制在某些从属副本未同步的情况下是否允许未同步的副本成为领导者。旧版本默认设置为 true，但在后续版本中更改为 false，以避免消息截断的问题。

 参数的组合，Kafka 可以在配置为 CP 系统时确保要么不工作，要么在获得确认后保证消息不会丢失且状态一致。

6.1.2 Kafka 配置为 AP（Availability & Partition tolerance）系统

在设置为 AP 系统时，可以使用以下参数配置：

request.required.acks = 1
min.insync.replicas = 1
unclean.leader.election.enable = false

通过合理配置生产者策略和 Kafka 集群的通用参数，开发者可以根据业务需求找到性能与消息可靠性之间的平衡。

一旦消息成功落到 Broker 上，Kafka 集群通过一定机制确保不同副本间的消息状态一致性。

HW 用于标识消费者可以读取的最大消息位置，而 LEO 则表示消息追加到日志中的最后位置。成功发送消息并不意味消费者就能够立即消费到这条消息。

enable.auto.commit = true
auto.commit.interval.ms = 5000 // 默认值为5秒

在这种配置下，消费者会在收到消息后自动向 Broker 返回确认。然而，如果业务逻辑未能完成而发生中断，那么可能会造成消息未成功消费的情况。此设置适用于对可靠性要求不高的场景，

在此设置下，开发者需要在完成消息处理后手动提交已消费的消息。如果在业务逻辑处理过程中发生重启，则未提交的消息会被重新消费，这会导致消息显然被重复投递。因此，该策略通常用于实现幂等性操作，确保即便发生重复消费，业务逻辑依然能保持一致。

Kafka的存储机制是保障数据可靠性的重要保障之一。通过对数据的写入过程、日志和索引文件的结构以及多副本和ISR机制的分析，我们可以了解到Kafka是如何确保数据不丢失的。当面临各种故障情况时，Kafka也能够通过自身的机制实现故障转移，保证数据的完整性和可靠性。

Kafka存储机制解析：如何确保数据不丢失？

本文深入探讨了Kafka的存储机制，包括存储选择、存储方案剖析、存储架构设计等内容，并详细介绍了Kafka如何通过日志分段和稀疏哈希索引来支持高效的数据存储和检索。同时，还讨论了Kafka在不同配置下的可靠性和故障转移机制。

后端

大数据

架构设计

Kafka为应对海量实时日志流处理需求，其存储架构采用顺序追加写日志与稀疏哈希索引，实现高效读写平衡。通过主题、分区、副本、分段等设计，满足高并发、高可用与高性能，确保数据可靠与系统稳定。

2026上云采购 | AI焕新·智启新局

message-queue-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

Kafka存储机制解析：如何确保数据不丢失？

Kafka存储机制解析：如何确保数据不丢失？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐