在同一个应用程序中，我发送具有完全不同格式且完全不相关的不同消息类型。解决此问题的最佳做法是什么？
我在这里看到了两种不同的方法：
【问题讨论】：
标签： google-cloud-platform publish-subscribe google-cloud-pubsub
您以 2. 点回答了您的问题。如果消息具有完全不同的格式并且完全不相关，则意味着它们应该分开。在应用层过滤它们没有任何优势。 Topics/subscriptions 模型正是为此目的而制造的。
主题和订阅之间的区别可能令人困惑。所以让我也描述一下。
首先是Pub Sub的概念：
发布订阅模型允许将消息异步广播到系统的不同部分。作为消息队列的兄弟，消息主题提供了一种广播异步事件通知的机制，以及允许软件组件连接到主题以发送和接收这些消息的端点。要广播消息，称为发布者的组件只需将消息推送到主题。现在主题和订阅的区别是一个主题可以有多个订阅，但一个给定的订阅属于一个主题。
总结一下：
【讨论】：
这取决于！与往常一样，但这取决于消息的使用方式。
使用消息属性来区分消息类型。由于此属性，您可以创建仅接受这些类型消息的订阅。像这样，您可以保持相同的主题，然后自定义调度。我wrote an article on this
【讨论】：
您可以通过三种方式解决此问题：
这三个选项需要权衡取舍。如果您可以控制发布者并且可以为不同的消息类型创建完全独立的主题，那么这可能是一个很好的方法，因为它将不同类型的消息保存在完全独立的通道上。可以将其想象为具有指定了更具体类型的数据结构。例如，在 Java 中，人们通常更喜欢List<String> 和List<Integer>，而不是包含两者的List<Object>。
但是，如果发布商归他人所有，这种方法可能不可行。如果订阅者无法知道可能需要从中消费的所有主题，这也可能是不可行的。想象一下，您添加了另一种类型的消息并创建了一个新主题。处理它需要创建另一个订阅者。如果消息类型的数量可能会变得非常多，您可能会发现自己在一个任务中拥有许多订阅者客户端。
如果在第二个和第三个选项之间进行选择，则取决于您的消费模式。它是需要处理这两种类型的消息的同一个应用程序，还是将其拆分为单独的应用程序是否有意义？如果拥有单独的应用程序是有意义的，那么单独的订阅是一个不错的方法。如果发布的消息可以在属性中区分它们的类型，那么您可能会使用Pub/Sub filtering 来确保每个订阅的订阅者只接收相关消息。
如果所有消息总是由同一个应用程序使用，那么单个订阅可能最有意义。最大的原因是成本：如果您有两个订阅和两个订阅者，这意味着所有消息都将被交付并支付两次。使用单个订阅并区分在应用程序级别完成的消息，消息仅传递一次（模 Cloud Pub/Sub 的至少一次传递保证）。如果订阅者不知道消息类型集并且可能随着时间的推移而增长，则最后一个选项特别有用。
因此，如果您可以控制发布者并且可以提前知道消息集，那么为每种消息类型设置单独的主题是最佳选择。如果不是这种情况，并且消息的处理可以由不同的应用程序完成，那么使用过滤器的不同订阅是最佳选择。如果所有消息类型的处理总是由同一个应用程序完成，或者类型的数量可能会增加，那么单个订阅是最佳选择。
【讨论】：