为什么kafka集群中的单节点多代理不受欢迎？

Question

我正在尝试将 kafka 实施到生产中。想知道为什么单节点、多代理 kafka 实例不是首选。很少有人建议如果在单个节点上使用多个代理，则应该为它们分配单独的磁盘空间，但这样做的原因尚不清楚。

有人可以解释单个代理与多个代理 kafka 实例对单个节点的影响。

Answer 1

如果在具有单个磁盘的单个节点上有多个代理，则所有代理都必须从单个磁盘读取和写入。这会让系统做大量的随机读取和随机写入，Kafka 集群的性能会很差。

相反，如果您在单个节点上有多个磁盘，并且每个代理读取和写入不同的磁盘，则可以避免随机读写问题。

更新

此外，如果您在一台机器上有太多的代理，网络带宽可能是一个瓶颈。由于所有经纪人都必须共享网络带宽。

Answer 2

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

分区 0：

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

分区 1：

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

现在一个Kafka集群是由多个broker组成的。每个代理都用一个 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），以便当一个代理宕机时，另一个代理可以提供主题的数据。例如，假设我们有一个有 2 个分区的主题，分区设置replication-factor为 2，如下所示：

经纪人1：

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

经纪人2：

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

经纪人3：

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

现在假设Broker 2发生故障。代理 1和 3 仍然可以为主题 1 提供数据。因此，replication-factor3 个代理始终是一个好主意，因为它允许出于维护目的而关闭一个代理，也允许意外关闭另一个代理。因此，Apache-Kafka提供了强大的耐用性和容错性保证。