Rebus FileSystemMessageQueue

Question

我發現Rebus包含FileSystemMessageQueue。這似乎太大了，是真實的，所以我要問幾個問題吧:)

1. 它是線程安全/過程安全

2. 難道事務

3. 爲什麼它使用JSON作爲序列化格式（與二進制串行器相比，它不會增加POCO的限制嗎？）

4. 它可以在沒有總線的情況下獨立工作嗎？ （就像單獨的dll，而不是服務）

5. 對於少量的消息，它可以替代MSMQ嗎？我的意思是，如果我們談論本地（非聯網），而不是資源密集型消息，它可以如何與MSMQ相比？它會和MSMQ一樣好嗎？

在此先感謝

Answer 1

的FileSystemMessageQueue開始了作爲一個有趣的實驗，因爲我想用的Dropbox作爲傳輸 - 這實際上似乎工作，但我沒有以任何方式進行了測試，除了通過運輸通過Rebus的通常運輸合同測試，並在幾次用戶組會議等中展示出來之外。）

因此：請理解，您將成爲測試運輸工具的一員，如果您確實使用它你幾乎可以立即成爲世界上與t的一員他在用它最有經驗:)

</disclamer>

1）運輸跟蹤哪些郵件文件，目前正在處理，以確保相同的文件不被接受的兩倍，因此您可以放心地有多個線程在同一端點接收消息。

雖然你不能做competing consumers，因爲目前沒有可以跨越多個進程的鎖定（可能可以通過使用操作系統鎖定文件並保留文件句柄來處理消息所需的時間）。

2）不可以。至少一次至少一次作爲Rebus中所有其他傳輸的傳遞保證，但它不是事務性的，也不能以原子方式提交其工作。

我已經讓傳輸延遲了傳出消息的實際寫入，因爲在消息處理程序中完成了自己的工作之後，消息對於收件人來說不會很快顯示 - 但從理論上講，可能會遇到這樣的情況，即發送一組傳出消息，然後刪除接收到的消息文件失敗，這將導致再次接收相同的消息 - 這就是爲什麼它被稱爲「至少一次」的原因;）

3）它使用JSON，因爲這是一種將對象寫入文件的簡單方法（即使使用配置的序列化程序對實際的消息主體進行序列化和編碼）。

4）???我不明白你的問題:)

5）是和否 - 我猜如果我們談論本地而不是資源密集型消息，它會和MSMQ一樣好。

我還沒有執行任何負載測試，但我猜測它會比MSMQ有關消息量慢得多。我認爲它能夠傳輸比MSMQ大得多的消息，因爲MSMQ仍然（據我所知）每個消息有4 MB的硬上限。