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