我有一个邮件阅读服务，它从收件箱中读取每封电子邮件，对其进行解析并将其插入数据库。我遇到的问题是不能保证我会按照收到的顺序解析电子邮件（这是业务需求）。我对此的解决方法是引入某种排队系统。通过这种方式，我将按照它们进入的顺序处理这些项目。这也将让我受益于将我对电子邮件的阅读和在数据库中解析/插入它们进行解耦。
所以我的问题是，如果我只打算在本地发送消息，那么使用服务总线（例如 NServiceBus）是否过大？这意味着读取电子邮件的服务和在数据库中解析/插入电子邮件的服务将驻留在同一台机器上。
谢谢你。
是的，这显然是矫枉过正，特别是因为 NServiceBus 不保证消息按顺序传递。
您可以只使用 a Queue<T>，假设您知道如何按顺序发送消息（这似乎是您遇到问题的地方，而不是您正在使用或未使用队列或其他任何东西；您必须知道如何获取项目以正确的顺序进入队列开始）。
KISS 和 YAGNI 全天、每一天都适用于此。
我只想为您的持久性问题提供一个 MSMQ。一旦它进入，它就保证在那里，不管机器断电，或者其他一些应用程序崩溃。
我不喜欢的单词。在我看来：让您的系统尽可能灵活，同时不影响应用程序可接受性能的限制（只有您可能知道）。
总的来说：为你能想到的最糟糕的营销决策做好准备。
这取决于。对于您的应用程序，我同意 Jason 的观点，服务总线不会像本地数据结构那样帮助您按顺序处理消息。而且，正如 Jason 所说，考虑到服务总线中的消息顺序无法保证，这很可能会更加困难。
但是，使用服务总线在本地发送消息可能非常有用。它使异步向其他进程发送消息变得非常容易。由于消息的使用者处于不同的进程中，因此您实际上没有任何线程问题。消息可以是持久的，因此您不必担心遗漏某些内容，并且只需添加一个新订阅者，就可以很容易地在事后为消息添加额外的处理。作为额外的奖励，如果系统变得太大而无法在一台机器上舒适地运行，那么分配总线将是微不足道的。
对于您的解决方案，这是不必要的，甚至可能会导致问题。但是在某些情况下，在本地使用服务总线是有意义的。
这是 ZeroMQ 运作良好的工作，对您的附带好处是您学习如何使用可以与其他语言和其他平台一起使用的工具。