我正在评估 Google Pub/Sub 与 Kafka。有啥区别？ [关闭]

Posted 2023-03-10

【中文标题】我正在评估 Google Pub/Sub 与 Kafka。有啥区别？ [关闭]

【英文标题】：I am evaluating Google Pub/Sub vs Kafka. What are the differences? [closed]我正在评估 Google Pub/Sub 与 Kafka。有什么区别？ [关闭]

【发布时间】：2016-11-29 01:12:50

【问题描述】：

我在 kafka 上工作不多，但想在 GCE 中构建数据管道。所以我们想知道 Kafka vs PUB/Sub。基本上我想知道消息一致性、消息可用性、消息可靠性在 Kafka 和 Pub/sub 中是如何维护的

谢谢

【问题讨论】：

不完全是您要找的东西，但也许对您来说会是一本有趣的书 - Spotify's journey to cloud: why Spotify migrated its event delivery system from Kafka to Google Cloud Pub/Sub

【参考方案1】：

我一直在阅读上面的答案，我想补充它们，因为我认为还有一些细节待定：

完全托管的系统 两个系统都可以在云端拥有完全托管的版本。 Google 提供了 Pubsub，并且有一些完全托管的 Kafka 版本，您可以在 cloud and On-prem 上进行配置。

云与本地我认为这是它们之间的真正区别，因为 Pubsub 仅作为 GCP 生态系统的一部分提供，而 Apache Kafka 您可以用作云服务和 On- prem service（自己做集群配置）

邮件重复 - 使用 Kafka，您需要自己管理消息的偏移量，使用外部存储，例如 Apache Zookeeper。通过这种方式，您可以跟踪消费者到目前为止读取的消息。 Pubsub 使用确认消息来工作，如果您的代码在截止日期之前未确认消息，则会再次发送消息，这样您就可以避免重复消息或使用 Cloud Dataflow PubsubIO 来避免的另一种方法。

保留政策 Kafka 和 Pubsub 都有配置最长保留时间的选项，默认情况下，我认为是 7 天。

Consumers Group vs Subscriptions请注意在这两个系统中阅读消息的方式。 Pubsub 使用订阅，您创建订阅，然后开始从该订阅中读取消息。一旦消息被读取并确认，该订阅的消息就消失了。 Kafka 使用“消费者组”和“分区”的概念，每个消费者进程都属于一个组，当从特定分区读取消息时，属于同一“消费者组”的任何其他消费者进程将无法阅读该消息（那是因为偏移量最终会增加）。您可以将偏移量视为一个指针，它告诉进程必须读取哪些消息。

我认为您的问题没有正确答案，这实际上取决于您需要什么以及您所拥有的限制（以下是一些场景示例）：

如果解决方案必须在 GCP 中，显然使用 Google Cloud Pubsub。您将避免所有设置工作或为 Kafka 所需的全自动系统支付额外费用。

如果解决方案需要流式处理数据，但还需要支持批处理（最终），使用 Cloud Dataflow + Pubsub 是个好主意。

如果解决方案需要使用一些 Spark 处理，您可以探索 Spark Streaming（您可以配置 Kafka 进行流处理）

总的来说，两者都是非常可靠的流处理系统。产生巨大差异的一点是，Pubsub 是附加到 GCP 的云服务，而 Apache Kafka 可以在云端和本地使用。

更新（2021 年 4 月 6 日）：

Finally Kafka without Zookeeper

【讨论】：

我认为这可能会产生误导；除非您想在 Kafka 有线协议上编写自己的库，否则现有客户端已经提供了可配置的机制来处理提交偏移量。此外，提交的偏移量不会保存在 Zookeeper 中，而是保存在一个特殊主题“__consumer_offsets”中，该主题在代理之间复制。这是一本好书：confluent.io/blog/…

确实我真的不明白你关于手动存储偏移量的说法：With Kafka you will need to manage the offsets of the messages by yourself, using an external storage, such as, Apache Zookeeper => 否决

【参考方案2】：

除了 Google Pub/Sub 由 Google 管理而 Kafka 是开源的之外，另一个区别是 Google Pub/Sub 是一个消息队列（例如 Rabbit MQ），而 Kafka 更多的是一个流式日志。您不能使用 Pubsub“重读”或“重播”消息。 （编辑 - 截至 2019 年 2 月，您可以重播消息并及时向后搜索到某个时间戳，根据下面的评论）

使用 Google Pub/Sub，一旦从订阅中读取并确认消息，它就会消失。为了让不同的读者阅读更多的消息副本，您可以通过为该主题创建“订阅”来“扇出”该主题，其中每个订阅都将拥有该主题中所有内容的完整副本。但这也增加了成本，因为 Google 根据从 Pub/Sub 读取的数据量收取使用费。

使用 Kafka，您可以设置一个保留期（我认为默认为 7 天），并且无论有多少消费者阅读它，消息都会留在 Kafka 中。您可以添加一个新的消费者（也称为订阅者），并让它在您想要的任何时候从主题的前面开始消费。你也可以将保留期设置为无限，然后基本上可以将Kafka作为不可变数据存储使用，如下所述：http://***.com/a/22597637/304262

Amazon AWS Kinesis 是 Kafka 的托管版本，而我认为 Google Pubsub 是 Rabbit MQ 的托管版本。 带有 SQS 的 Amazon SNS 也类似于 Google Pubsub（SNS 提供扇出，SQS 提供队列）。

【讨论】：

重放是大多数面向事件架构的关键特性。此外，Kafka 给消息添加了一个序列号，因此成为了序列的权威来源。

使用像 PubSub 这样的消息队列系统完成“重播”的方法是将主题扇出到更多订阅（即制作更多消息副本），每个消费者消费自己的按照自己的节奏订阅。我想您可以订阅仅用于在需要时重播的订阅。要对 Kafka 做同样的事情，您将创建一个新的消费者并从前面开始消费（因为 Kafka 不会复制消息，它只是给每个消费者自己的“指针”偏移量来跟踪什么是已阅读）

Kinesis 可以被认为是在语义上类似于 Kafka 的托管服务，但说它是“Kafka 的托管版本”是不准确的。有关实际的“托管 Kafka”，请参阅 Confluent Cloud confluent.io/confluent-cloud

Cloud Pub/Sub 最近添加了对重播之前确认的消息的支持。 quickstart guide 和 blog post 解释了如何使用该功能。

假设你有一个监听器。它在收到消息后醒来，做一些工作，然后崩溃。它正在处理的事件会发生什么？使用回放+序列号，您始终可以存储最后已知的良好状态 + 序列号并从上次中断的地方继续。

【参考方案3】：

Kafka 与 Cloud Pub/Sub 的一大区别是 Cloud Pub/Sub 完全为您管理。您不必担心机器、设置集群、微调参数等，这意味着您可以处理大量 DevOps 工作，这很重要，尤其是当您需要扩展时。

【讨论】：

这并没有真正的区别，因为有多家供应商也将 Kafka 作为完全托管的服务提供。不同之处可能在于 Google PubSub 仅在 Googles Cloud 中作为服务提供，因此没有本地版本，也没有在 AWS 或 Azure 等其他云提供商中运行的托管服务。

“Google PubSub 仅作为 Googles Cloud 中的服务提供”不正确...您的应用程序与部署在 Google App Engine 中无关...您可以连接并发布到 GooglePub/Sub “来自任何客户，只要您通过“服务帐户”安全地连接到它。

@JerylCook 我认为他只是意味着你不能在 prem 上安装 google 的 pub/sub