众所周知，rabbitMQ 之类的消息总线主要用于异步消息传递，因此标准方法是触发并忘记在总线上发布某些内容，而不必担心谁将处理已发布的消息或何时处理。但是我正在考虑我们开发团队中关于消息同步处理的最新讨论:案例是将消息发布到服务总线，作为发布者，我想等待任何订阅者处理消息并将结果返回给我 - 所以它看起来而是作为请求-响应模型。我现在在想一个缺点，比如在这个模型中降低性能。你怎么看？何时使用异步，何时使用同步？有哪些权衡？
最佳答案
同步消息是可能的，但 影响可扩展性 .如果发布者必须等待其接收者做出响应，那么它在任何给定时间所能实现的目标都会受到限制。
但是，您可以使用异步消息传递来实现请求-响应。在 RabbitMQ 中，您可以通过 Remote Procedure Call (RPC) 来做到这一点。图案。
简而言之，您的发布者发布消息，但不等待响应；同时它可以继续做其他事情。发布者确实通过在消息上放置一个 CorrelationId 并将其存储在本地来跟踪它。消息最终到达消费者，消费者处理它并响应不同队列中的发布者。回复具有相同的 CorrelationId。当发布者收到回复时，它可以将该特定调用(通过 CorrelationId)标记为已处理。
如果需要，您还可以使用 CorrelatonId 做其他事情，例如超时那些我们没有收到回复的消息，例如30秒。
关于asynchronous - RabbitMQ 同步消息的优缺点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46714609/