Kafka系列第6篇：消息是如何在服务端存储与读取的，你真的知道吗？

前言

经过前 5 篇文章的介绍，估么着小伙伴们已经对消息生产和消费的流程应该有一个比较清晰的认识了。当然小伙伴们肯定也比较好奇，Kafka 能够处理千万级消息，那它的消息是如何在 Partition 上存储的呢？今天这篇文章就来为大家揭秘消息是如何存储的。本文主要从消息的逻辑存储和物理存储两个角度来介绍其实现原理。

文章概览

1. Partition、Replica、Log 和 LogSegment 的关系。

2. 写入消息流程分析。

3. 消费消息及副本同步流程分析。

Partition、Replica、Log 和 LogSegment 的关系

假设有一个 Kafka 集群，Broker 个数为 3，Topic 个数为 1，Partition 个数为 3，Replica 个数为 2。Partition 的物理分布如下图所示。

Partition分布图

从上图可以看出，该 Topic 由三个 Partition 构成，并且每个 Partition 由主从两个副本构成。每个 Partition 的主从副本分布在不同的 Broker 上，通过这点也可以看出，当某个 Broker 宕机时，可以将分布在其他 Broker 上的从副本设置为主副本，因为只有主副本对外提供读写请求，当然在最新的 2.x 版本中从副本也可以对外读请求了。将主从副本分布在不同的 Broker 上从而提高系统的可用性。

Partition 的实际物理存储是以 Log 文件的形式展示的，而每个 Log 文件又以多个 LogSegment 组成。Kafka 为什么要这么设计呢？其实原因比较简单，随着消息的不断写入，Log 文件肯定是越来越大，Kafka 为了方便管理，将一个大文件切割成一个一个的 LogSegment 来进行管理；每个 LogSegment 由数据文件和索引文件构成