考虑以下设置：
- 单个Kafka主机
- 单一主题
- 多个分区
在这种情况下，所有分区都在同一物理主机上。
我的理解是分区执行三个功能：
- 数据弹性
- 负载平衡
- 区域分布？(CDN)
我不完全确定最后两个。最后一点我可能错了，因为我在Kafka API或设置配置中看不到任何允许这样做的机制。
详细解释每一个。
数据剩余量：
如果存在多个分区，并且消息被复制到多个分区中，则数据会根据分区的故障进行调整。这可以使用"；复制因子"；。分区必须位于不同的物理主机上，否则这将不起作用。
负载平衡：
Kafka似乎有一个自动负载平衡机制，根据Round Robin机制将消息分发到分区。如果消息中提供了一个密钥，则会使用哈希算法来确保具有相同密钥的所有消息都分布到相同的分区，但在这种情况下，我们仍然需要负载平衡，因为可能会有多个消息密钥在使用。(并非所有消息都有相同的密钥。)
CDN：
如果Kafka主机分布在全球各地，那么来自消费者的消息更有可能分布到地理位置相近的主机上是有道理的，这是很自然的，因为这些主机可能具有更低的延迟和更高的带宽连接。我相信，尽管我不完全确定，卡夫卡在这方面的行为有点像CDN，因为它做的事情就像自动选举领导人一样。
然而，我可能错了，所以如果不是这样的话，请纠正我。
单个主机还是多于主机的分区
这些观点提出了一个有趣的问题。既然在同一台主机上可以有多个分区，而且我们可以有比主机更多的分区，那么这样做的目的是什么？
在极端情况下，只有一个主机和至少两个分区，我们就无法获得上述任何好处。没有故障转移或数据恢复。没有负载平衡效应或低延迟连接选择效应。
那么，这样做的目的是什么呢？
参考：https://www.dataversity.net/how-to-overcome-data-order-issues-in-apache-kafka/#
分区不是为了恢复，与服务器数量无关。复制副本对两者都是。
"负载平衡"；例如，在Kafka中不会像HTTP服务那样预先执行。正如您所说，记录被散列并分发到分区，或者您可以明确地告诉生产者或消费者写入任何可用的分区。此外，无论负载如何，客户端请求总是到分区的leader broker。
因此，我认为这不是为了负载平衡(因为它与服务器/客户端负载无关)，而是为了吞吐量。如果您只有一台主机，那么很明显，您会受到这台机器的磁盘和网络速度的限制。类似地，一台机器是一个单点故障，所以是的，主机上永远不应该有多个代理(Kafka甚至不允许您将replication.factor设置为高于代理计数)。(我想，理论上，你可以运行单独的Kafka JVM进程，用不同的磁盘存储日志，但YMMV，因为联网会很奇怪)
对于多个代理，客户端不会在没有手动干预的情况下决定代理上的分区位置(kafka-reassign-partitions)。这就是考虑负载分布的地方，但它是在"；最好的努力，箱包装"；，仍然不是"；负载"；因为代理无法预测分区将如何使用。因此，当一台主机上使用多个分区，并且有多核CPU和多个物理磁盘安装到Kafkalog.dirs设置的卷中时，只有这样才能在一台机器内正确平衡负载但是，这仍然取决于客户端读取/写入均匀分布的数据，否则您将得到"热分区"；并开始填充磁盘，使代理脱机。如果数据总是无密钥的，并且总是使用默认的partitioner，那么就不用担心了。
Kafka(和Zookeeper)更喜欢低延迟，所以不，一个集群不应该是"低延迟"；全球"；。建议您不要在云提供商(区域隔离、独立的数据中心)的可用性区域之外部署集群。如果你需要一个全局分布式的Kafka设置，你可以部署区域集群，并使用MirrorMaker2、Confluent Cluster Links等工具，或者切换到Apache Pulsar等其他项目(并启用其与Kafka客户端兼容的功能)
关于引用的博客，当添加代理或增加主题分区时，Kafka不会自动重新平衡自己。