我是企業Java開發新手，雖然我確信這個問題同樣適用於任何語言或平臺，如.NET。何時，何地以及如何使用隊列？
這是我第一次現在正在處理消息隊列，我對它們非常感興趣。 （具體來說，我們使用的是ActiveMQ）。我的技術主管希望ActiveMQ隊列成爲我們所有數據庫和內部Web服務的領跑者;因此而不是從客戶端觸發數據庫查詢並直接進入數據庫，它首先被排隊。
我的問題是這樣的：隊列的方式去每主要處理組件？最佳實踐是否決定將它們放在系統組件的前面，這些組件通常會遇到大量請求？有沒有隊列不應該使用的情況？
感謝您的任何見解！有
http://code.google.com/p/disruptor/
不僅隊列是在野外解決這些類型的問題：
以下是消息隊列可能有用的一些示例。
有限的資源
比方說你有大量的用戶發出請求到服務的。如果服務只能同時處理少量的請求，那麼你可以使用一個隊列作爲緩衝區。
服務脫鉤
重點企業整合概念在例如工作流去耦的系統。系統不是直接相互對話，而是將消息異步發佈到隊列中。集成組件然後將消息路由並傳遞給適當的系統。
消息重放
在上述例子中隊列也可以提供請求的可靠傳遞和處理。如果工作流程的一個組件中斷，其他組件不受影響，仍然可以操作並將消息發佈到已損壞的組件。當損壞的組件恢復時，它可以處理所有排隊的消息。
這裏的關鍵概念是負載調節，鬆耦合，可靠性和異步操作。
至於他們是否會選擇的每個主要組件，我會說不，這不是自動選擇，您必須單獨考慮每個組件。
請看看這個。
回答你的問題。這種情況下的隊列將在訪問數據庫時引入異步行爲。在這種情況下，更重要的是您能否對您的遺留系統產生如此巨大的影響。將所有內容推送到隊列中可能太多了。請說明您的系統的一般用途。那麼完全回答你的問題會很容易。
隊列確實是一個非常強大和有用的工具，但是就像每個工具一樣，你只應該將它用於它所打算的工作。
IMO他們不客場去爲每主要處理組件。
作爲一般規則，我會使用請求資源不需要立即同步響應的隊列。我不會使用加工的時間和順序至關重要的隊列。
如果異步處理是允許的，並且您希望管理到服務的流量，那麼排隊可能是。
查看@ Qwerky的回答也是，他（或她）提出了一些要點。
消息隊列基本上是一個異步通信系統。在這種情況下，這意味着除了鏈接發送者和接收者的隊列之外，發送者和接收者都獨立運行;消息的接收者不（並且不應該）需要與發送者進行交互。類似地，消息的發送者不（並且不應該）需要與接收者交互。
如果發送方需要等待處理消息的結果，那麼消息隊列可能不是一個好的解決方案，因爲這會迫使異步系統與核心設計同步。在消息隊列之上構建一個同步通信系統是可能的，但消息隊列的基本異步特性會使這種轉換變得笨拙。