设计 Kafka 消费者和生产者以实现可扩展性

如何解决设计 Kafka 消费者和生产者以实现可扩展性

我想设计一个解决方案，用于向多个提供商发送不同类型的电子邮件。总体概述。

我有几个上游提供商 Sendgrid、Zoho、Mailgun 等。它们将用于发送电子邮件等。例如：

• 注册新用户的电子邮件
• 删除用户的电子邮件
• 空间配额限制的电子邮件

（一般来说大约有 6 种类型的电子邮件）

每种类型的电子邮件都应该生成到生产者中，转换成序列化的 Java 对象并发送到与上游提供者集成的适当的 Kafka 消费者。

问题是如何设计 Kafka 以获得最大的性能和可扩展性？

• 到目前为止，我可以考虑是否要为每种类型的电子邮件和每个网关设置主题（6x4 = 24 个主题）的第一个解决方案。将来我希望添加更多类型的消息和网关。也许它会达到600个主题。这将产生大量用于维护的 Java 源代码和大量需要管理的主题。另一个缺点是 Kafka 日志会很大。

• 第二个解决方案是为每个消费者（集成网关）使用 1 个主题。但是在这种情况下，我如何根据要发送的消息类型发送每种类型的不同序列化 Java 对象？

是否有更好的方法来设计此设置，以便我可以更轻松地扩展它并使其在未来的集成中非常强大？

您可以在这里看到我如何在消费者和生产者之间发送消息：org.apache.kafka.common.KafkaException: class SaleRequestFactory is not an instance of org.apache.kafka.common.serialization.Serializer

编辑：

1. 订单很重要，因为沟通将是异步的。生产者将等待返回的消息状态
2. 将每个网关的数据保持在不同的主题上并不重要
3. 你想要什么样的隔离？ 我不想将消息/主题彼此完全隔离，以防止将来需要添加更多网关或消息类型时出错

将每个网关的数据保存在不同的主题上对您来说重要吗？ - 不，我只想隔离 hte 数据。

如果您要为每个网关使用一个主题，您是否关心它会在客户端产生的开销？ - 读取不必要的消息，编写更多逻辑，混合序列化器等

我不知道这里。我的主要考虑是通过新功能使系统易于扩展。

解决方法

我认为每个事件类型一个主题对于您提到的运营开销来说确实太多了。

我认为选项 2 是正确的方法 - 每个集成网关一个主题，有专门的消费者。优点是：

• 您在主题级别隔离工作负载（集成网关 A 上的许多消息不会影响网关 B 的使用者）
• 您可以根据主题工作负载扩展消费者

生产者会根据网关的要求对消息进行序列化，并将其发布到特定主题上。消费者只会阅读消息并推送它。

,

不幸的是，这里没有简单的答案。
您需要问自己几个问题，然后从几个权衡中进行选择 -

首先，顺序重要吗？是否只是您想从 A 点转发到 B 点的电子邮件？，还是您想（我猜您会）将事件的合理顺序保留到同一实体（例如 - 关于用户创建的邮件需要在关于更改密码的同一新用户的邮件之前收到。）

如果顺序很重要，最好使用带有 partitioning key 的相同主题，因为 Kafka 仅在分区级别保证消息的顺序。

你想要什么样的隔离？将每个网关的数据保持在不同的主题上对您来说很重要吗？
如果您要为每个网关使用一个主题，您是否关心它将在客户端产生的开销？ - 读取不必要的消息，编写更多逻辑，混合序列化器等

您能估计一下您要缩放的维度吗？ - 如果您采用第一个解决方案，每个网关和事件类型的主题，突然间您需要添加 100 倍的网关，这不一定是正确的调用。此外，如果您需要更快地处理 User-Change-Emails 会发生什么？ - more partitions lead to higher throughput - 你能这样做吗？

---

Confluent 很少有关于这些主题的精彩文章可能对您有所帮助 -

Should You Put Several Event Types in the Same Kafka Topic?

How to choose the number of topics/partitions in a Kafka cluster?