如何實現消息隊列解決方案

Question

我有一個場景，其中約10個不同的消息需要入隊然後出隊/處理。一個用戶需要全部10條消息，但另一個用戶只需要10條消息中的8條。我想了解設置這種架構的最佳方法是什麼。您是否爲每種消息類型創建了一個隊列，以便訂閱者可以訂閱相關隊列，或者將它們全部轉儲到同一個隊列並忽略與該訂閱者無關的消息？我想確保該溶液是柔性的/可擴展的，等等

過程：

1. 10不同的XML消息將被排隊到一個IBM WebSphere MQ服務器。
2. 我們將使用的.Net（最有可能的，因爲WCF的WebSphere MQ 7.1 WCF支持已添加）
3. 我們將出列郵件並將其加載到其他後端數據庫（最有可能的SQL服務器）。
4. 解決方案需要很好的擴展，因爲我們將處理大量的消息，並且這種消息可能會增長（可能達到40-50,000 /小時）。至少對我們來說很大。

一如既往地非常感謝的信息。

--S

Answer 1

好的，根據評論，這裏有一個建議，可以擴展，並且不需要對應用程序進行太多改變。

在生產者方面，我會將消息選擇標準複製到消息屬性，然後將消息發佈到主題。此應用程序所需的唯一更改是消息屬性。如果出於某種原因，您不想使用本機功能進行發佈，則可以在主題上定義別名。該應用程序認爲它正在發送消息，但它們確實是出版物。

在消費者方面，您有幾個選擇。一種是爲每個應用程序創建管理訂閱，並在訂閱中使用選擇器。然後根據選擇標準將消息彙集到每個消費者的專用隊列中。這些應用程序認爲他們只是消費信息。

另外，應用程序可以簡單地訂閱主題。這使您可以選擇動態訂閱，當應用程序斷開連接時（如果實際上您想要的話）不會收到消息，或者是與管理訂閱在功能上等效的持久訂閱。

該解決方案可輕鬆擴展至您引用的數量。另一種選擇是生產者不使用屬性。在這裏，消費者應用程序使用的所有消息，符開消息負載上的每個並決定是否處理或忽略該消息。在這個解決方案中，製作人仍然在發佈一個主題。涉及直排隊的任何解決方案都會迫使生產者知道所有的目的地。添加另一位消費者，更改制作人。另外，每個目的地都有一個PUT。

最壞的情況是生產者將多條消息，並具有讀取每一個決定，如果它要被忽略消費者。該選項可能存在擴展問題，具體取決於選擇標準字段在有效負載中的深度。很長的XPath表達式=性能差，沒辦法調WMQ來彌補它，因爲等待時間都在該點的應用程序。

最佳情況下，生產者設置一個消息屬性和發佈。消費者在他們的訂閱中選擇屬性或者管理訂閱爲他們做這件事。就可伸縮性而言，此解決方案使用應用程序訂閱還是管理訂閱無關緊要。

Answer 2

創建隊列相對「便宜」從資源的角度來看，加是的，它是更好地使用隊列爲每個特定的目的，因此它可能是在這種情況下，最好通過目標客戶將它們分開如果可能的話。根據一些標準（相關ID或其他事物）選擇使用隊列來選擇拉消息通常是一個壞主意。消息傳遞中表現最佳的場景是最簡單的：在隊列到達時從隊列中簡單地拖出消息，而不是選擇性地進行查看和接收。關於擴展，我不能說Websphere MQ或其他IBM產品，但每小時40-50K消息對於Windows Server上的MSMQ並不特別困難，所以我會假定IBM可以做到這一點以及。通常瓶頸不是排隊平臺本身，而是出列和處理單個消息的過程。