【问题标题】:Is Kafka suitable for running a public API?Kafka 是否适合运行公共 API?
【发布时间】:2016-10-02 16:26:57
【问题描述】:

我有一个想要发布的事件流。它被划分为主题,不断更新,需要水平扩展(并且没有 SPOF 很好),并且在某些情况下可能需要重播旧事件。似乎与 Kafka 的功能相匹配的所有功能。

我想通过任何人都可以连接并获取事件的公共 API 将其发布到全世界。 Kafka 是否适合作为公共 API 公开?

我已经阅读了文档页面,但还没有深入。 ACL 似乎是明智的。

我的担忧

  1. 消费者将在世界任何地方。我不认为这是查看 Kafka 架构的问题。消息的速率可能不会超过每秒 10 条。

  2. 与 zookeeper 的集成是否存在问题?

  3. 是否有任何反对让我无法控制的订阅者客户端连接的论点?

【问题讨论】:

  • 就个人而言,我会使用另一个系统来前端它。事实上,我愿意。我使用 NodeJS 处理与客户端的通信,并使用kafka-node 处理 Kafka 和 Node 之间的通信。除其他事项外,我记得在某处读到“没有人使用 ACL”,这让我担心依赖它们——缺乏使用等于很有可能出现问题。您还可能遇到防火墙/安全问题。我知道这不是您正在寻找的答案 - 因此这是一条评论。
  • 不,这正是我正在寻找的答案,谢谢。你在做什么其他范围的节点?网络套接字?你能恢复中断的流吗?
  • 我使用engine.io。我最初使用socket.io 和 websockets,但由于不需要开销,所以降到了较低的级别。我此时没有使用自动重新连接——但您可以使用engine.io 来实现。然后,只需使用client-id 标记您的客户端,并在客户端使用localStorage 和在NodeJS 服务器端使用Map() 保持上下文。
  • 这里有一个非常简单的 socket.io 服务器从 kafka 主题读取的示例:github.com/confluentinc/demo-scene/blob/master/ksql-workshop/…

标签: apache-kafka kafka-consumer-api


【解决方案1】:
  1. 是否有任何反对让我无法控制的订阅者客户端连接的论点?

我会考虑的一个问题是group.id 可能发生冲突。

假设您有一个主题可供全世界使用来消费您的消息。

现在,如果您的一个客户端有一个多节点系统并且想要避免两次读取相同的消息,他们会为两个节点设置相同的group.id,形成一个消费者组。

但是,如果世界上其他人使用相同的 group.id 怎么办?它们会影响第一个客户端,导致它丢失消息。该级别似乎没有安全措施。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-02-02
    • 2021-04-23
    • 1970-01-01
    • 2022-01-09
    • 1970-01-01
    • 2018-05-20
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多