【问题标题】:Are Kafka and Kafka Streams right tools for our case?Kafka 和 Kafka Streams 是否适合我们的案例?
【发布时间】:2021-04-23 15:44:03
【问题描述】:

我是 Kafka 新手,如果有任何建议,我将不胜感激 我们正在更新旧版应用程序,并将其从 IBM MQ 移至其他应用程序。

应用程序当前执行以下操作:

  • 读取批量 XML 消息(最大 5 MB)
  • 将其解析为有意义的内容
  • 以某种方式手动并行处理部分批次的数据。涉及一些导致数据库更改的外部旧 API 调用
  • 发送多种电子邮件通知
  • 向其他队列发送一些回复
  • 输入消息被配置到磁盘

我们正在考虑将 Kafka 与 Kafka Streams 一起使用,因为它很好

  • 轻松扩展处理
  • 开箱即用地永久存储消息
  • 内置分区、复制和容错
  • Confluent Schema Registry 让我们迁移到 schema-on-write
  • 也可用于其他应用程序的服务到服务通信

但我有些担心。

根据我的理解,我们正在考虑以逻辑方式拆分这些大消息并以这种方式将它们放入 Kafka - Kafka 不是大消息的忠实拥护者。它还可以让我们在分区的基础上并行处理。

之后,使用 Kafka Streams 进行实际处理,并进一步使用状态存储聚合一些批处理响应。还可以将一些消息推送到其他一些主题(例如发送电子邮件)

但我想知道在 Kafka Streams 中进行实际处理是否是个好主意,因为它涉及一些外部 API 调用?

此外,当此外部 API 因任何原因而关闭时,我不确定处理这种情况的最佳方法是什么。这意味着当前和所有后续消息的临时故障。有什么方法可以停止 Kafka Stream 处理一段时间吗?我可以看到 Consumer API 上有 Pause 和 Resume 方法,它们可以在 Streams 中以某种方式使用吗?

在这里使用普通的 Kafka 消费者是否更好,可能会添加 Streams 作为下一步将这些批处理消息合并在一起?听起来有点复杂

卡夫卡是实现这些目的的好工具吗?

【问题讨论】:

  • archie_by - 有几个问题需要进一步理解。您是否因为扩展问题而从 IBM MQ 迁移到 kafka?您是否计划处理数百万个事件而不是关键任务消息?使用 IBM MQ,消费者完成的队列中的 MQ GET 是破坏性读取,但在 kafka 的情况下,此逻辑将转移到消费者,以确保它不会两次处理相同的事件。

标签: apache-kafka apache-kafka-streams


【解决方案1】:

总的来说,我认为你会很好地使用 Kafka,也可能使用 Kafka Streams。我建议将流用于您需要执行的任何逻辑,即您必须执行的过滤或映射。您想使用连接器或标准生产者编写的地方。

虽然最好使用较小的消息,但我已经看到流用户在 GB 中有消息。

您可以从 Kafka 流处理器进行远程调用、发送和发送电子邮件,但不建议这样做。编写事件以向输出主题发送电子邮件并使用普通消费者读取和发送消息可能会更好。这也可以解决您对 API 关闭的担忧,因为您始终可以记住最后的偏移量,以防万一并从那里重新启动。或者使用 Pause 和 Resume 方法。

【讨论】:

    猜你喜欢
    • 2022-01-22
    • 2017-06-09
    • 2022-10-13
    • 2020-08-08
    • 2018-01-19
    • 2019-01-31
    • 1970-01-01
    • 2019-09-04
    • 2020-04-25
    相关资源
    最近更新 更多