Kafka-分区(Partition)和副本(Replica)

作者介绍：简历上没有一个精通的运维工程师，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

我们上一章介绍了中间件：Zookeeper，本章将介绍另外一个中间件：Kafka。目前这2个中间件都是基于JAVA语言的。

我们上个小节介绍了Kafka里面一个很核心的逻辑概念：主题(Topic)，在创建Topic的时候，涉及到两个很关键的参数：分区(Partition)和副本(Replica)，我们今天就来详细介绍这2个概念。

Kafka 中的 分区（Partition） 和 副本（Replica） 是两个核心概念，它们共同支撑了 Kafka 的高吞吐量、可扩展性和高可用性。以下是它们的详细解释和关系：

1. 分区（Partition）

定义：分区是 Topic 的物理分片，每个 Topic 可以划分为多个分区。每个分区是一个有序、不可变的消息队列，消息按顺序追加到分区末尾。分区在 Kafka 集群的多个 Broker 上分布式存储。可以简单理解就是把Topic再进一步分成多份。

核心作用并行性：生产者可以同时向多个分区写入数据，消费者可以并行读取多个分区，提升吞吐量。水平扩展：通过增加分区数，Topic 的容量和吞吐量可线性扩展。消息顺序性：同一分区的消息是有序的，但不同分区的消息顺序无法保证。

关键特性：分区数量，在创建 Topic 时指定，后续可动态增加（但减少分区需谨慎）。分区分配策略：由 Kafka Producer 根据消息的 key 或自定义规则决定消息写入哪个分区；而分区本身的物理分配（即哪些分区在哪些 Broker 上）则由 Kafka 集群在创建或调整 Topic 时完成。

2. 副本（Replica）

定义：副本是分区的冗余备份，每个分区可以有多个副本（由 replication factor 参数控制）。副本分为两种角色：

• Leader Replica：处理所有读写请求，是唯一对外服务的副本。
• Follower Replica：异步或同步地从 Leader 复制数据，不直接处理客户端请求。

核心作用：高可用性，当 Leader 副本所在的 Broker 宕机时，Follower 副本可被选举为新的 Leader，确保服务不中断。数据持久性，多个副本分布在不同的 Broker 上，避免数据丢失。

关键机制：ISR（In-Sync Replicas），所有与 Leader 保持同步的副本集合（包括 Leader 自身）。只有 ISR 中的副本才有资格被选举为 Leader。同步策略：Follower 定期从 Leader 拉取数据（通过 fetch 请求），保持与 Leader 的同步。

注意：这里的副本副本（Replica）设置为2，则总数是2份，而不是有2个备份。

3. 分区与副本的关系

在上个小节我们提到，如果向一个不存在的Topic发送消息，如果我们允许它创建，则会读取默认的配置，这个默认的配置是下面2个参数：

• num.partitions: 定义了自动创建的 Topic 默认有多少个分区。
• default.replication.factor: 定义了自动创建的 Topic 的默认副本因子（包括原始的消息副本）。

如果我们使用Kafka的脚本创建也是读取这2个参数，他们默认都是1。