每个主题，都是一个特定的数据流（类似于数据库中的表）。主题，被分成 partitions（任意数量），其中分区中的每条消息都有一个增量 id，称为偏移量，如下所示。
分区 0：
+---+---+---+-----+
| 0 | 1 | 2 | ... |
+---+---+---+-----+
分区 1：
+---+---+---+---+----+
| 0 | 1 | 2 | 3 | .. |
+---+---+---+---+----+
现在一个 Kafka 集群由多个 brokers 组成。每个代理都有一个 ID 标识，并且可以包含某些主题分区。
2 个主题的示例（每个主题分别有 3 个和 2 个分区）：
经纪人 1：
+-------------------+
| Topic 1 |
| Partition 0 |
| |
| |
| Topic 2 |
| Partition 1 |
+-------------------+
经纪人 2：
+-------------------+
| Topic 1 |
| Partition 2 |
| |
| |
| Topic 2 |
| Partition 0 |
+-------------------+
经纪人 3：
+-------------------+
| Topic 1 |
| Partition 1 |
| |
| |
| |
| |
+-------------------+
请注意，数据是分布式的（Broker 3 不保存 topic 2 的任何数据）。
主题，应该有一个replication-factor > 1（通常是 2 或 3），这样当一个代理关闭时，另一个可以提供主题的数据。例如，假设我们有一个主题有 2 个分区，replication-factor 设置为 2，如下所示：
经纪人 1：
+-------------------+
| Topic 1 |
| Partition 0 |
| |
| |
| |
| |
+-------------------+
经纪人 2：
+-------------------+
| Topic 1 |
| Partition 0 |
| |
| |
| Topic 1 |
| Partition 0 |
+-------------------+
经纪人 3：
+-------------------+
| Topic 1 |
| Partition 1 |
| |
| |
| |
| |
+-------------------+
现在假设 Broker 2 失败了。 代理 1 和 3 仍然可以为主题 1 提供数据。因此，replication-factor 为 3 始终是一个好主意，因为它允许一个代理被删除以进行维护，也允许另一个代理被删除出乎意料地被取下来。 因此，Apache-Kafka 提供了强大的持久性和容错保证。
关于领导者的注意事项：
在任何时候，只有一个代理可以成为分区的领导者，并且只有该领导者可以接收和提供该分区的数据。其余的代理只会同步数据（同步副本）。另请注意，当 replication-factor 设置为 1 时，leader 在代理失败时无法移动到其他位置。一般来说，当一个分区的所有副本都失败或下线时，leader 会自动设置为-1。
话虽如此，只要您的生产者列出了集群中所有 Kafka 代理的地址 (bootstrap_servers)，您应该没问题。即使一个代理关闭，您的生产者也会尝试将记录写入另一个代理。
最后，确保设置acks=all（虽然可能会影响吞吐量），以便所有同步副本确认他们收到了消息。