对于创建操作，很明显，将消息放在队列中是一个好主意，以防该实体的处理或创建所需的时间超过预期的时间，而其他好处排队队列带来的其他好处。
但是，对于读取时间的读取操作（必须在不到3秒钟内返回UI），尚不完全清楚队列是否是个好主意。
http://masstransit-project.com/masstransit/usage/request-response.html提供了一个不错的抽象，但它通过了队列。
有人可以提供一些建议，说明为什么或为什么我不使用大众运输，或者对nservicebus等任何技术进行数据库读取操作（UI）的时间限制？我应该仅在长期运行过程中使用质量运输吗？
请求/回复是时间夏季操作的完全有效模式。例如，兔子的运输成本非常低。我使用ServiceStack（非常快）和MassTransit测量了请求/响应的性能。MassTransit有一个最初的延迟来缓存端点，但是除此之外，速度几乎相同。
这里的好处是：
- 重试
- 超时的微调
- 与竞争的消费者轻松扩展
仅命名最明显的
，并且通过错误处理，您会得到您的请求以错误队列结束，因此没有数据丢失，您可以随时查找那里以找出出了什么以及为什么出了问题。
update ：有一个SOA模式描述了此方法（或相似）。它称为解耦调用。