消息排隊模式

Question

我們有兩個架構。 實質上，它們形成了生產者和消費者。 第1部分（p1）將消息發布到處理消息的第2部分（第2頁），此過程涉及將消息發送到遠程節點，該消息必須在消息處理完消息后對其進行處理，此過程最多可能需要幾秒鍾。

p2在其隊列中具有有限長度，並且在從遠程節點接收到ack之前不會移除項目。 由於這個p2可以返回對p1的QUEUE_FULL響應。 當p1收到此響應時，它會保留一個隊列，每當產生一條新消息時，它會將其添加到此隊列的末尾，然后循環通過隊列向p2發送消息，直到它再次獲得QUEUE_FULL。 這里的問題是，一旦p2的隊列為空/有空間，它就無法通知p1產生消息。

對於p2中生產者的每個實例，p1中都有一個相應的生產者，這對於下面的潛在解決方案很重要。

一個解決方案可能是p2可以更改為在其隊列中有空間時通知p1，但是此解決方案需要相當大的網絡開銷（http），因為在任何時候都有數千個p2隊列需要通知他們相應的p1生產者。

另一個解決方案可能是p1可以更改為繼續嘗試將消息發送到p2。 這個問題是p1中的生產者需要在嘗試發送下一條消息之前有一個休眠x的線程，顯然可能有一個處理這種睡眠/重試機制的單例，但是這里的邏輯，生產者和消費者增加到成千上萬，變得相當復雜;

• 添加，刪除，生成器同步
• 閱讀隊列，進行下一次閱讀時間
• 低生產者計數時緊密循環的考慮因素
• 高生產者數量時長時間等待的考慮因素
• ......等

我接近建議一個MQ層，其中p1發布到，p2讀取。 然而，這引入了一個新問題，其中p2在遠程節點消失時無法通知p1，但是這可以通過從p2到p1的http回調來處理 - 這里的開銷水平是可接受的，因為遠程節點的可能性是離開很低。

我錯過了一個設計模式，它將不再需要MQ（另一個服務需要擔心，監控等）？ 非常感謝。

其他一些細節：

• 每個p1生成器實例大部分都是請求作用域
• 每個p2使用者都是一個專用的運行線程

Answer 1

麥克風，

看起來這個過程有很大的復雜性（有可能引入更多）只是為了避免使用MQ？ 根據我的經驗，可能有很多理由不使用MQ，但是如果你有權使用它，那就放棄使用它！ :)它比監視代碼以引入類似功能更容易監視新的MQ進程。

理想情況下，強大的隊列會阻止P1真正需要了解P2或其狀態。

MQ還應該真正減少P2通知P1其遠程節點發生故障的需要 - P1可以繼續愉快地將消息排隊到P2（取決於消息頻率/大小/存儲限制）。 如果遠程節點停機了很長時間，那么希望這是一個計划的事件，操作員可以關閉P1。 P2和P1之間的管理通道聽起來很不錯？

它還引入了額外的復雜性 - 你知道你的環境，但它可能導致諸如“為什么我不再收到消息？”之類的問題。 - 事實證明服務自動關閉另一項服務。 做得好，這很棒，減輕了操作員的支持負擔 - 做錯了，只會增加更多的支持負擔。 沒有人喜歡那個人。

您是否也可以在數據層排隊，P2的存儲可能不是一個問題？

擁抱隊列（MQ，MSMQ，Sql Queue）！

ž

Answer 2

回顧3種可能性

• 那么為服務命令打開另一個MQ（而不是http調用）;
• 認為p2是多線程的，其中一個沒有等待的線程從MQ中提取消息，並將它們放到另一個線程進行處理;
• （！）使用MQ的事務版本 - 所以p2可以立即提取消息，p1可以盡可能快地放置它。 但是如果處理失敗，隊列將被回滾。