如果在同一个节点上有多个代理，那么最终可能只有一个节点上的一个主题的所有分区。如果该节点失败，则特定主题将变得无响应。

如果在具有单个磁盘的单个节点上有多个代理，那么所有代理都必须从单个磁盘读写。这使得系统进行了大量的随机读写操作，而kafka集群的性能较差。
相反，如果在一个节点上有多个磁盘，并且每个代理从不同的磁盘读写，则可以避免随机读写问题。
更新
另外，如果一台机器上有太多代理，网络带宽可能是一个瓶颈。因为所有的代理都必须共享网络带宽。

像大多数事情一样，这个问题的答案是“视情况而定”。你的问题本质上是泛泛的。如果您能更具体地说明您对系统的哪些属性感兴趣（性能、可用性等），这会有所帮助。从性能的Angular 来看，如果box（节点）上有大量的示例，那么如果它有大量的资源，就可以了。但从可用性的Angular 来看，这对您没有帮助，即如果某个节点发生故障，您的系统将出现单点故障并面临巨大风险（除非您有多个这样的高资源节点可供您使用：-））

每个主题都是一个特定的数据流（类似于数据库中的表）。主题被划分为多个分区（可以任意多个分区），分区中的每条消息都获得一个增量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提供了强大的持久性和容错保证。