我是企业Java开发的新手，虽然我确信这个问题同样适用于任何语言或平台，例如.NET。
现在我第一次处理消息队列，我对他们非常感兴趣。 （具体来说，我们使用的是ActiveMQ）。我的技术主管希望ActiveMQ队列成为我们所有数据库和内部Web服务的领跑者;因此，不是从客户端发出数据库查询而是直接转到数据库，它首先排队。
我的问题是：排队等待每个主要处理组件？最佳实践是否要求将它们放在通常会受到大量请求影响的系统组件之前？是否存在不应使用队列的情况？
感谢您的任何见解！
答案 0 :(得分：8)
以下是一些消息队列可能有用的示例。
资源有限
假设您有大量用户向服务发出请求。如果服务只能同时处理少量请求，那么您可以使用队列作为缓冲区。
服务脱钩
关键的企业集成概念是例如工作流程中的系统的分离。它们不是让系统直接相互通信，而是异步地将消息发布到队列中。然后，集成组件将消息路由并传递到适当的系统。
消息重播
在上面的示例中，队列还可以提供可靠的请求传递和处理。如果工作流的一个组件中断，则其他组件不受影响，仍然可以操作并将消息发布到损坏的组件。当损坏的组件恢复时，它可以处理所有排队的消息。
这里的关键概念是负载限制，松散耦合，可靠性和异步操作。
至于它们是否是每个主要组件的方式，我会说不，这不是一个自动选择，你必须单独考虑每个组件。
答案 1 :(得分：5)
队列确实是一个非常强大且有用的工具，但是就像每个工具一样，你应该只将它用于预期的工作。
IMO他们不远离每个主要处理组件。
作为一般规则，我会使用一个队列，其中请求资源不需要立即的同步响应。我不会使用时间和处理顺序至关重要的队列。
如果允许异步处理并且您希望规范服务的流量，那么队列可能成为可行的方式。
请参阅@ Qwerky的答案，他（或她）提出了一些好处。
答案 2 :(得分：0)
请查看：
http://code.google.com/p/disruptor/
不仅有野外队列来解决这些问题。
回答你的问题。在这种情况下，队列将在访问您的数据库时引入异步行为。在这种情况下，您可以承受如何对遗留系统产生如此巨大的影响。将一切推向队列可能只是太多的改变。请描述一下系统的一般用途。那么完全回答你的问题会更容易。
答案 3 :(得分：0)
消息队列基本上是异步通信系统。在这种情况下，这意味着除了链接发送方和接收方的队列之外，发送方和接收方都独立运行;消息接收者不（也不应该）要求与发送者进行交互。同样，消息的发送者不会（也不应该）需要与接收者进行交互。
如果发送方需要等待处理消息的结果，那么消息队列可能不是一个好的解决方案，因为这会迫使异步系统与核心设计同步。有可能在消息队列之上构建同步通信系统，但消息队列的基本异步特性会使这种转换变得尴尬。