为什么不首选kafka集群中的单节点多代理？答案

【问题标题】：Why single node multiple broker in kafka cluster not preferred?为什么不首选kafka集群中的单节点多代理？
【发布时间】：2021-10-16 01:13:34
【问题描述】：

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

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

【问题讨论】：

标签： apache-kafka kafka-consumer-api

【解决方案1】：

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

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

更新

另外，如果单台机器上有太多代理，网络带宽可能会成为瓶颈。由于所有代理都必须共享网络带宽。

【讨论】：

感谢您的回复。我所阅读和观察到的是，kafka 代理的 CPU 密集度较低，并且正如您所说，读/写繁重。因此，与其让多个代理分别在不同的机器上运行，不如增加磁盘并使用一台没有内核的强大机器。这样我将不得不使用更少的物理机器。这是一个好方法吗？？
@Aditya 如果单台机器上有太多代理（即使您有多个磁盘），网络带宽可能会成为瓶颈。由于这些代理必须共享网络带宽。所以这是否是一个好方法取决于你的生产环境，你必须做一个基准测试。

【解决方案2】：

每个主题，都是一个特定的数据流（类似于数据库中的表）。主题，被分成 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 1     |
+-------------------+

经纪人 3：

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

现在假设 Broker 2 失败了。 代理 1 和 3 仍然可以为主题 1 提供数据。因此，replication-factor 为 3 始终是一个好主意，因为它允许一个代理被删除以进行维护，也允许另一个代理被删除出乎意料地被取下来。 因此，Apache-Kafka 提供了强大的持久性和容错保证。

【讨论】：

【解决方案3】：

与大多数事情一样，这个问题的答案是“视情况而定”。你的问题本质上是通用的。如果您可以更具体地说明您对系统的哪些属性感兴趣 - 性能、可用性等，这将有所帮助。从性能的角度来看，如果盒子（节点）上有很多实例，那么它有很多资源。但从可用性的角度来看，它对您没有帮助，即您的系统将出现单点故障，并且如果该节点碰巧发生故障，将面临巨大风险（除非您有多个如此高资源的节点供您使用:-)）

【讨论】：

【解决方案4】：

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

【讨论】：