綁定到羣集MSMQ實例的MSMQ郵件被阻塞在傳出隊列中

Question

我們爲一組NServiceBus服務集羣了MSMQ，並且一切都運行良好，直到沒有爲止。一臺服務器上的外出隊列開始填滿，很快整個系統就被掛起。

更多細節：

我們有服務器N1和N2之間的羣集MSMQ。其他集羣資源只是作爲本地，即NServiceBus分發器直接在集羣隊列上運行的服務。

所有工作進程都位於不同的服務器，服務3和服務4上。

對於那些不熟悉NServiceBus的人來說，工作會進入由分銷商管理的集羣工作隊列。 Service3和Services4上的工作人員應用程序將「我準備好工作」消息發送到由同一分銷商管理的集羣控制隊列，分銷商通過向工作進程的輸入隊列發送一個工作單元作出響應。

在某個時候，這個過程可能會完全掛起。這裏是羣集MSMQ實例傳出隊列的照片時，系統掛起：

如果我失敗羣集到另一個節點上，它就像整個系統被在褲子踢。這裏是相同的羣集MSMQ實例的故障轉移後不久，一個畫面：

誰能解釋這種行爲，並且我能做些什麼來避免它，以保持系統順暢運行？

Answer 1

過了一年之後，似乎我們的問題已經得到解決。關鍵看起來是：

• 確保您有一個穩定的DNS系統，因此當MSMQ需要解析主機時，它可以。
• 僅在Windows故障轉移羣集上創建MSMQ的一個羣集實例。

當我們建立了我們的Windows故障轉移羣集，我們的假設，這將是不好的「廢物」資源的非活動節點上，因此，當時有兩個準相關NServiceBus集羣，我們做了Project1的羣集MSMQ實例和Project2的另一個羣集MSMQ實例。大多數時候，我們認爲，我們會在單獨的節點上運行它們，並且在維護窗口期間它們將共同位於同一節點上。畢竟，這是我們爲SQL Server 2008的主要和開發實例所做的設置，並且一直運行良好。

在某些時候，我開始懷疑這種方法，尤其是因爲每個MSMQ實例一次或兩次故障轉移似乎總是讓消息再次移動。

我問Udi Dahan（NServiceBus的作者）關於這個集羣託管策略，他給了我一個困惑的表達，並問：「爲什麼你會想要做這樣的事情？實際上，分銷商的重量非常輕，所以沒有太多理由將它們均勻分配到可用節點中。

之後，我們決定把我們學到的一切和recreate a new Failover Cluster with only one MSMQ instance。自那以後我們還沒有看到這個問題。當然，確保這個問題得到解決將會被證明是一種消極的，因此是不可能的。至少6個月沒有問題，但誰知道呢，我想它明天可能會失敗！我們希望不要。

Answer 2

您的終端配置如何保持其訂閱？

如果您的服務中的一個（或多個）服務遇到錯誤並且由Failoverclustermanager重新啓動，該怎麼辦？在這種情況下，該服務將再也不會收到來自其他服務的「我準備好工作」消息之一。

當你故障轉移到另一個節點時，我想你的所有服務都會再次發送這些消息，因此一切都會恢復正常。

要測試此行爲，請執行以下操作。

1. 停止並重新啓動您的所有服務。
2. 只停止其中一項服務。
3. 重新啓動停止的服務。
4. 如果您的系統沒有掛起，請對每項服務重複此操作。

如果您的系統現在再次掛起，請檢查您的配置。在這種情況下，至少有一個（如果不是全部）服務會在重新啓動之間丟失訂閱。如果您尚未這樣做，請將訂閱保留在數據庫中。

Answer 3

也許你的服務器被克隆，因此共享相同的隊列管理器ID（QMId）。

MSMQ將QMId用作緩存遠程機器地址的散列。如果網絡中有多臺計算機具有相同的QMId，則可能會收到卡住或丟失的消息。

閱讀本博客文章的解釋和解決方案：http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx