多主题消息队列

Question

我有一个关于微服务架构的理论性问题。

假设我们有两个微服务 A 和 B 通过 RabbitMQ 相互交互。当 A 有问题时，它会向 queue_1 发送消息并通过 queue_2 从 B 接收答案（因此通信可以保持异步）。

            ------------
       --->   queue_1    --->
   A        ------------      B
            ------------
      <---   queue_2     <---
            ------------

现在我了解到 A 可能会提出至少 4 种不同的问题。我的问题是配置它的最佳方法是什么？

是否可以为每种问题创建一个单独的队列对（这样它们就不会混在一起，并且更容易确定，期望什么样的答案）？

或者它是否被认为不是非常理想，最好为所有消息创建一个通道并将它们路由到微服务中？

如果能提供有关此主题的任何链接和信息，我将不胜感激。

Answer 1

没有简单的答案；彻底分析真实场景并确定合适的结构是架构师的工作。

假设请求类型是 W、X、Y 和 Z。为简单起见，假设每个队列只有一个消费者。如果 W 和 X 可以快速处理，而 Y 和 Z 是冗长的操作，那么将所有内容都放在一个队列中意味着一旦 Y 或 Z 位于队列顶部，那么任何排队的 W 和 X 都会花费很多时间time enqueued，等待消费者完成运行漫长的过程。在这种情况下，最好为 Ws 和 Xs 使用一个队列，为 Ys 和 Zs 使用另一个队列。

想想现实生活中的排队服务，比方说一家超市。您有通往收银台的正常通道，也有 "up to 10 products" 条快速通道。

另一件需要考虑的事情是：您是否希望对每种请求类型应用不同的策略和保证？例如，Ws 可能是 "document messages" 每隔一段时间到达一次，你不能丢失（需要持久化到磁盘），并且无论何时调度它们都必须处理（没有 "time-to-live")，而 X 是一直到达的 "event messages"，必须快速处理，并且只在几秒钟内有效（具有短 TTL）。这意味着他们需要不同的队列。

也许 Ys 和 Zs 有不同的优先级：也许你必须尽快处理 Zs，即使有待处理的 Ys。这将再次调用不同的队列。

如果所有请求类型的重要性等都相同，那么为了简单起见，单个队列可能会更好。

同样的讨论也适用于响应队列。您可以有四个不同的请求队列和一个响应队列。或四个响应队列，或两个...（它不必是对称的）。

还有其他问题需要考虑，例如安全性、可伸缩性和性能。

实际的路由并不是真正的挑战，使用消息头可以很容易地帮助确定哪个处理程序应该处理每种消息类型（您不必检查实际的消息正文来确定其类型），这是真的就像拥有不同的队列一样简单。

多主题消息队列

Multi-topic message queue(s)

message-queue

rabbitmq