每个主题都是一个特定的数据流（类似于数据库中的表）。主题被划分为多个分区（可以任意多个分区），分区中的每条消息都获得一个增量id，称为偏移量，如下所示。
分区0:

+---+---+---+-----+
| 0 | 1 | 2 | ... |
+---+---+---+-----+

分区1：

+---+---+---+---+----+
| 0 | 1 | 2 | 3 | .. |
+---+---+---+---+----+

现在，Kafka集群由多个代理组成。每个代理都用一个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不包含主题2的任何数据）。
主题，应该有一个 replication-factor >1（通常是2或3），这样当一个代理关闭时，另一个代理可以提供一个主题的数据。例如，假设一个主题有两个分区，每个分区有一个 replication-factor 设置为2，如下所示：
经纪人1：

+-------------------+
|      Topic 1      |
|    Partition 0    |
|                   |
|                   |
|                   |
|                   |
+-------------------+

经纪人2：

+-------------------+
|      Topic 1      |
|    Partition 0    |
|                   |
|                   |
|     Topic 1       |
|   Partition 0     |
+-------------------+

经纪人3：

+-------------------+
|      Topic 1      |
|    Partition 1    |
|                   |
|                   |
|                   |
|                   |
+-------------------+

现在假设代理2失败了。代理1和3仍然可以为主题1提供数据。所以 replication-factor 3总是一个好主意，因为它允许一个经纪人为了维护的目的被拆掉，也允许另一个经纪人意外地被拆掉。因此，apachekafka提供了强大的持久性和容错保证。
关于引线的注意：在任何时候，只有一个代理可以是分区的引线，并且只有该引线可以接收和服务该分区的数据。其余的代理将只同步数据（同步副本）。还要注意的是 replication-factor 如果设置为1，则在代理失败时不能将引线移到其他位置。通常，当一个分区的所有副本都失败或脱机时 leader 将自动设置为 -1 .
话虽如此，你的制作人列出了集群中所有Kafka经纪人的地址( bootstrap_servers )，你应该没事的。即使一个经纪人破产了，你的制作人也会试图把记录写给另一个经纪人。
最后，确保设置 acks=all （可能会影响吞吐量），以便所有同步副本都确认它们已收到消息。