我有一個郵件閱讀服務，可以從收件箱中讀取每封電子郵件，解析並將其插入到數據庫中。我遇到的問題是，我無法保證我將解析電子郵件以便收到它們（這是業務需求）。我的解決辦法是引入某種排隊系統。這樣我就可以按順序處理這些項目。這也會給我帶來的好處是，我可以解讀電子郵件，並將它們解析/插入到數據庫中。如果所有消息都在本地發送，使用服務總線是否過分矯枉過正？
所以我的問題是，如果我只打算在本地發送消息，它使用服務總線（如NServiceBus）是矯枉過正？這意味着將讀取電子郵件的服務以及解析/插入數據庫中的電子郵件的服務將駐留在同一臺計算機上。
謝謝。
是的，這顯然是矯枉過正，尤其是因爲NServiceBus不能保證消息按順序。
假設您知道如何按順序獲取消息（這似乎是您遇到問題的位置，而不是您正在使用或未使用隊列或任何其他位置;您必須使用Queue<T>知道如何以正確的順序將物品放入隊列中以開始）。
KISS和YAGNI適用於這裏，全天，每天。
1000x是。我們很少在這裏看到明確的答案。這是一個明確的答案。 – Stimul8d
會字我不喜歡。在我看來：儘可能使系統靈活多變，而不會影響應用程序可接受性能的限制（只有您可能知道）。
一般來說：準備好您可以想到的最糟糕的營銷決策。
這取決於。對於您的應用程序，我同意Jason的觀點，服務總線不會幫助您處理消息，而不僅僅是本地數據結構。而且，正如Jason所說，考慮到服務總線中的消息順序不能保證，它很可能會更難更多。
但是，使用服務總線在本地發送消息可能非常有用。它使異步發送消息到其他進程非常容易。由於消息的消費者處於不同的過程中，因此您並沒有真正的線程問題。消息可以是持久的，因此您不必擔心會丟失某些內容，並且只需添加新的訂閱者就可以事後爲消息添加額外的處理過程。作爲額外的獎勵，如果系統變得太大而無法在一臺機器上運行，那麼分配總線將是微不足道的。
對於您的解決方案，這是不必要的，甚至可能導致問題。但有些情況下，在本地使用服務總線是有意義的。
我只想給我們一個關於持久性問題的MSMQ。一旦進入，它將保證在那裏，無論機器是否失去能力，或者其他應用程序崩潰。
這是ZeroMQ運行良好的工作，對您的好處是您可以學習如何使用可與其他語言和其他平臺一起使用的工具。
如果您知道將它們添加到隊列中的順序，爲什麼您不能只改變邏輯來按照該順序處理項目？ –
因此，您正在考慮讓一項服務讀取電子郵件，將其放入一個隊列中，另一項服務讀取隊列並將信息放入數據庫中？如果您目前的流程不能保證按照他們進來的順序處理電子郵件，我不知道如何輸出到隊列將有助於... – Daryl
@本 - 好點。由於我無法控制的問題，某些組件可能會崩潰。如果在處理隊列時發生崩潰。這幾乎是確保系統中的任何故障不會導致電子郵件丟失的一種方法。 – gcso