具有不同消息类型的Google Cloud Pub / Sub

如何解决具有不同消息类型的Google Cloud Pub / Sub

在同一应用程序中，我发送格式完全不同且完全不相关的不同消息类型。解决此问题的最佳实践是什么？

我在这里看到两种不同的方法：

1. 应用程序级别的过滤器，这意味着我在同一个合并器（相同订阅）上收到所有消息
2. 创建一个新的订阅，这意味着该应用程序将有两个正在运行的Puller（每种消息类型一个）

解决方法

您以2.点回答了您的问题。如果消息格式具有完全不同的格式并且完全不相关，则意味着应将它们分开。在应用程序层对其进行过滤没有任何优势。 Topics/subscriptions模型正是为此目的而制作的。

主题和订阅之间的区别可能令人困惑。因此，我也要描述一下。

第一个概念Pub Sub：

• 主题：发布者向其发送消息的命名资源。在发布/订阅模型中，发布到该主题的任何消息都会立即被该主题的所有订阅者接收。
• 订阅：一种命名的资源，代表单个特定主题中要传递给订阅应用程序的消息流。
• 消息：发布者发送到主题并最终传递给订阅者的数据和（可选）属性的组合。
• 消息属性：发布者可以为消息定义的键/值对。

此图演示了Pub / Sub模型

“发布订阅”模型允许将消息异步广播到系统的不同部分。消息主题是消息队列的兄弟姐妹，它提供了一种广播异步事件通知的机制，以及允许软件组件连接到主题以便发送和接收那些消息的端点。要广播消息，称为发布者的组件只需将消息推送到主题即可。现在，主题和订阅之间的区别在于，一个主题可以有多个订阅，但是给定的订阅属于一个主题。

总结：

• 要发布消息时使用主题。
• 要使用邮件时使用订阅。

,

这取决于！！与往常一样，但这取决于消息的使用方式。

• 如果它们被同一应用程序使用，请使用相同的订阅。
• 如果消息是由其他应用程序使用的（因为消息不相关且结构不同），请使用2个订阅。

使用message属性来区分消息类型。由于有了此属性，您可以创建仅接受这些类型的消息的订阅。这样，您可以保留相同的主题，然后自定义调度。我wrote an article on this

,

有三种方法可以解决此问题：

1. 将不同类型的消息发布到不同的主题，然后为每个主题创建订阅，并使用每个订阅中的消息。
2. 将不同类型的消息发布到同一主题，创建一个订阅，并使用该订阅中的所有消息。
3. 将不同类型的消息发布到同一主题，创建两个订阅，并针对每个订阅在订阅者上按类型过滤消息。

这三个选项之间需要权衡。如果您拥有对发布者的控制权，并且可以为不同的消息类型创建完全独立的主题，那么这将是一个很好的方法，因为它可以在完全独立的渠道上保留不同类型的消息。可以将其视为具有指定了更具体类型的数据结构。例如，在Java中，通常首选List<String>和List<Integer>而不是同时包含两者的List<Object>。

但是，如果发布者由其他人拥有，则此方法可能不可行。如果订户无法知道可能有必要从中吸收的所有主题，那么这也不可行。假设您添加另一种消息并创建一个新主题。处理它需要创建另一个订户。如果消息的类型数量增加很多，那么您可以在一个任务中发现有很多订阅者客户端。

如果在第二个和第三个选项之间进行选择，则决定取决于您的消费方式。是需要处理两种类型消息的同一个应用程序，还是将其拆分为单独的应用程序有意义？如果拥有单独的应用程序有意义，那么单独的订阅是一个不错的选择。如果发布的消息具有在属性中区分其类型的方式，则可以潜在地使用Pub/Sub filtering来确保每个订阅的订阅者仅收到相关的消息。

如果所有消息总是要由同一应用程序使用，则单个订阅可能最有意义。造成这种情况的最大原因是成本：如果您有两个订阅和两个订阅者，则意味着所有消息将被发送并支付两次。通过单次订阅并区分在应用程序级别完成的消息，消息仅发送一次（模数Cloud Pub / Sub的至少一次发送保证）。如果订户不知道消息类型集并且消息类型会随着时间增长，则最后一个选项特别有用。

因此，如果您可以控制发布者，并且可以提前知道消息集，那么最好使用每种消息类型的单独主题。如果不是这种情况，并且消息的处理可以由不同的应用程序完成，那么使用过滤器进行不同的订阅是最好的选择。如果所有消息类型的处理总是由同一应用程序完成，或者类型的数量可能会增加，则最好使用单个订阅。