Kafka 架构多分区还是多主题？

Posted 2023-03-10

【中文标题】Kafka 架构多分区还是多主题？

【英文标题】：Kafka architecture many partitions or many topics?

【发布时间】：2018-07-22 03:24:30

【问题描述】：

我希望将 Kafka 设置为来自 IoT 机器的数据和将处理该数据的服务之间的中介。 我在确定根据我的用例设计主题的正确方法时遇到了一些问题，希望得到一些建议。

我希望从多台机器上读取传感器数据，每台机器都可以有许多传感器。例如（温度、压力、零件等） 我的消费者将阅读的这些消息的顺序很重要，需要按顺序排列。

我想出了三种可能的设计，但我不确定哪个最好，如果有的话？

a) 每台机器将写入具有 1 个分区的特定主题以保证顺序。所以机器 100 将写入名为：machine100TempSensor1、machine100TempSensor2、machine100PressureSensor1 等的主题。

b) 所有机器都将写入单个主题，但分区将基于机器/传感器，因此使用与上述相同的示例， 机器 100 将写入名为“温度”的主题，但将键入机器和传感器。

例如。 （主题：温度，分区：machine100TempSensor1） （主题：温度，分区：machine100TempSensor2） （主题：温度，分区：machine200TempSensor1）

c) 为温度主题生成所有与温度相关的消息，并在我处理数据时过滤这些消息。

我对所有解决方案的担忧，

a) - Kafka 仅保证分区级别的顺序，因此创建具有单个分区的主题是一个好主意，还是违背了主题应该是什么？ - 如果我想从所有机器上读取“温度”，我必须知道特定主题的名称和请求数据，而不是一般的“温度”主题。 - Kafka 声明只有一个消费者组可以从单个分区读取，所以我必须创建许多消费者组。

b) - 如果我考虑扩展，如果不是 100 秒/1000 秒，单个“温度”主题可能有 30 多个分区。 （但我将受益于一次读取所有分区） - 由于只有一个消费者组能够从单个分区中读取数据，因此我将为每个消费者创建一个消费者组。

c) - 我觉得过滤数千条无用消息可能会带来很大的性能成本。 - 在将处理后的数据推送到 kafka 时，我会遇到同样的问题。

需要考虑的是，我希望能够处理某些机器/传感器。

希望我能够清楚地解释一切。

【参考方案1】：

您对 Kafka 的总体理解并非 100% 正确。

1) Kafka 基本上可以扩展分区——因此，对于代理来说，如果您使用 1 个主题和 1000 个分区、1000 个主题和每个分区 1 个分区，则没有区别（从性能角度来看）。 （如果您打算使用 Kafka Streams（又名 Streams API），使用具有 1000 个分区的单个主题会更好，因为 Kafka Streams 不能很好地跨主题扩展。）

2) 如果基本上绝对没问题，创建单个分区主题以保证排序。对于一次订阅多个主题，如果您相应地命名主题，则可以使用模式订阅。

3) 单个代理可以托管数千个分区。因此，即使考虑到复制，您也不需要庞大的集群。

4) 这种说法听起来不正确（或者我可能错过了理解）：

Kafka 声明只有一个消费者组可以从一个分区中读取，所以我必须创建许多消费者组。

也许你的意思是，一个消费者组内只有一个消费者。那将是正确的。如果您有一个消费者组，您可以将每个分区分配（手动或使用内置的消费者组管理）到组内最多一个消费者。如果多个应用程序要读取同一个分区，您只需要多个消费者组。

5) 您对 (c) 的担忧似乎是合理的。

【讨论】：

太棒了，感谢您抽出宝贵时间回复我。我想我会选择b，让所有机器写入一个“温度”主题并使用分区进行排序。如果我理解正确，“所有写入请求都通过领导者，领导者将写入传播给跟随者。”，我担心的是当写入的数据超过单个代理的能力时会发生什么？由于我的所有分区都在一个代理上，我可以指定其他代理作为这些分区的领导者吗？