我構建的應用程序需要保留它發送的消息的副本,以便我可以在以後階段重播所有消息。這是必要的,因爲在開發過程中消息的處理將發生顯着變化,但是數據必須儘快捕獲,因爲它是實時觀測數據。我似乎無法找到任何直接解決此問題的內置功能,而我可以編寫自定義工具來保存數據,這似乎與首先使用NServiceBus的目的相矛盾。有些選項我考慮:NServiceBus消息重播存檔體系結構
使用目標總線創建歸檔隊列,並建立使用這種歸檔隊列作爲輸入隊列簡單地將消息轉發到目標總線的簡單應用程序的ForwardReceivedMessagesTo功能只要Replayer工具運行。這會清除存檔隊列,要求先使用mqbkup實用程序先備份它,但這可以作爲重放過程的一部分自動執行。或者,使用兩個交替存檔隊列(一個接收新消息,另一個接收重放)可以解決這個問題。
使用發佈/訂閱模型並讓Archiver訂閱目標隊列,將郵件放入存檔隊列中。與上面類似的Replayer工具可以使用Archive隊列作爲輸入隊列並將消息轉發給目標。這也將清除存檔隊列,需要上述解決方案之一。
MassTransit人員提到了一種叫做BusDriver的東西,它允許在隊列之間進行復制,但我找不到任何關於它的更多信息。
我最關心的是選擇是最不容易丟失數據,因爲一旦觀察是由它永遠不會被一個狹窄的時間窗口之外再提出的辦法。這似乎應該是一個普遍的問題,但我似乎無法找到一個簡單的解決方案。建議?
更新我已決定使用已記錄的目標隊列。我將讓Archiver使用日誌作爲輸入並將消息存儲到數據庫(可能只是基於文件),並允許將數據庫中的消息重播到目標隊列。儘管可以編寫一個將日誌隊列中的消息複製到目標隊列的工具,但從實際角度來看,真正的問題是管理日誌隊列:它無法輕鬆備份(mqbkup降低MSMQ服務,這是不可接受的),並且在隊列上非破壞性地運行需要我編寫基於MSMQ的工具,而我寧願堅持NServiceBus抽象級別。最終,MSMQ是一種傳輸方式,而不是一種消息存儲方式,因此需要將其作爲一種處理方式。
+1的日誌,它可能是最簡單的選項。 – 2011-03-12 19:44:13
據我瞭解,ReturnToSourceQueue將刪除歸檔隊列中的消息,這將清除歸檔。進一步的研究表明,使用mqbkup來備份歸檔隊列會降低MSMQ服務的性能,這是不可接受的。感謝您將日誌記錄引入我的視線;它比ForwardReceivedMessagesTo要好,因爲它確保消息的副本存在,而不管訂閱者隊列是否接受它。仍然存在非破壞性地重放消息的問題。我用我目前的結論更新了我的問題,以備將來參考。 – 2011-03-14 14:41:44