进程间消息传递 - MSMQ、Service Broker？
我正处于 .NET 服务的规划阶段，该服务不断处理传入消息，其中涉及各种转换、数据库插入和更新等。作为一个整体，该服务庞大而复杂，但它执行的单个任务很小，简单且定义明确。
出于这个原因，并且为了将来能够轻松扩展，我想将服务拆分为几个较小的服务，这些服务基本上执行部分处理，然后再将其传递到链中的下一个服务。
为了实现这一目标，我需要某种中间消息传递系统，将消息从一个服务传递到另一个服务。我希望这种情况以这样的方式发生：如果链中的链接崩溃或短暂离线，消息将开始排队并在目的地恢复在线后得到处理。
我一直使用消息队列来处理此类事情，但最近发现 SQL Service Broker 似乎可以做类似的事情。 SQLSB 是否是此场景的可行替代方案？如果是，我是否会通过使用它而不是标准消息队列看到任何性能优势？
谢谢
I'm in the planning stages of a .NET service which continually processes incoming messages, which involves various transformations, database inserts and updates, etc. As a whole, the service is huge and complicated, but the individual tasks it performs are small, simple, and well-defined.
For this reason, and in order to allow for easy expansion in future, I want to split the service into several smaller services which basically perform part of the processing before passing it onto the next service in the chain.
In order to achieve this, I need some kind of intermediary messaging system that will pass messages from one service to another. I want this to happen in such a way that if a link in the chain crashing or is taken offline briefly, the messages will begin to queue up and get processed once the destination comes back online.
I've always used message queuing for this type of thing, but have recently been made aware of SQL Service Broker which appears to do something similar. Is SQLSB a viable alternative for this scenario and, if so, would I see any performance benefits by using that instead of standard Message Queuing?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我看来，您可能正在追求服务总线架构。这将为您提供所需的协调性和容错能力。我最熟悉也最偏爱的是 NServiceBus，但还有其他一些，包括 Mass Transit 和 Rhino Service Bus。
It sounds to me like you may be after a service bus architecture. This would provide you with the coordination and fault tolerance you are looking for. I'm most familiar and partial to NServiceBus, but there are others including Mass Transit and Rhino Service Bus.
如果这些步骤中的大多数从数据库状态开始并以数据库更新结束，那么将消息存储与数据存储合并就很有意义：
此外，还需要认真考虑性能，因为让消息存储与数据存储相同意味着您不需要对每个消息交互进行两阶段提交。使用单独的消息存储需要您将消息存储和数据存储注册到分布式事务中（即使位于同一台计算机上），这需要两阶段提交，并且比单独数据库事务的单阶段提交慢得多。
此外，与外部消息存储相比，使用数据库中的消息存储具有可查询性（在消息队列上运行 SELECT）等优点。
现在，如果我们将抽象术语“数据库中的消息存储”翻译为 Service Broker，将“非数据库消息存储”翻译为 MSMQ，您就会明白我的观点为什么 SSB 会随时围绕 MSMQ 运行。
If most of these steps initiate from a database state and end up in a database update, then merging your message storage with your data storage makes a lot of sense:
In addition there are also serious performance considerations, as having your message store be the same as the data store means you are not required to do two-phase commit on every message interaction. Using a separate message store requires you to enroll the message store and the data store in a distributed transaction (even if is on the same machine) which requires two-phase commit and is much slower than the single-phase commit of database alone transactions.
In addition using a message store in the database as opposed to an external one has advantages like queryability (run SELECT over the message queues).
Now if we translate the abstract terms 'message store in the database as being Service Broker and 'non-database message store' as being MSMQ, you can see my point why SSB will run circles any time around MSMQ.
我最近使用这两种方法（从 Sql Server Service Broker 开始）的经历让我陷入了因从 SQL Server 获取消息而哭泣的情况。这个问题是准政治性的，但您可能需要考虑一下：我的组织中的 SQL 服务器由专门的 DBA 管理，而应用程序服务器（即像 NServiceBus 这样的消息传递）由开发人员和网络团队管理。对数据库服务器的任何更改都需要 DBA 进行痛苦的性能分析，并且担心我们可能会因为位于同一空间的排队引擎而承担标准 SQL 职责。
SSSB 相当难以管理（与消息传递中间件不同），但不同之处在于，我更容易在消息传递世界中搞砸一些事情（可能发生的最糟糕的情况是在某处堆积一堆消息并填满日志）并且我无法承受 SQL 世界中的任何错误，因为客户事务数据在 SQL 世界中存在并且对业务至关重要（包括来自遗留系统的数据）。我真的不想再收到那些“意外的数据库增长”或“等待时间警报”或“为什么我的临时数据库不断增长”的电子邮件。
我了解到应用程序服务器很便宜。只需添加消息处理程序、添加机器......很简单。几乎没有许可费用。对于 SQL Server，情况恰恰相反。现在在我看来，使用 Service Broker 进行消息传递就像使用昂贵的汽车来犁土豆地一样。对于其他事情来说要好得多。
My recent experiences with both approaches (starting with Sql Server Service Broker) led me to the situation in which I cry for getting my messages out of SQL server. The problem is quasi-political but you might want to consider it: SQL server in my organisation is managed by a specialized DBA while application servers (i.e. messaging like NServiceBus) by developers and network team. Any change to database servers requires painful performance analysis from DBA and is immersed in fear that we might get standard SQL responsibilities down by our queuing engine living in the same space.
SSSB is pretty difficult to manage (not unlike messaging middleware) but the difference is that I am more allowed to screw something up in the messaging world (the worst that may happen is some pile of messages building up somewhere and logs filling up) and I can't afford for any mistakes in SQL world, where customer transactional data live and is vital for business (including data from legacy systems). I really don't want to get those 'unexpected database growth' or 'wait time alert' or 'why is my temp db growing without end' emails anymore.
I've learned that application servers are cheap. Just add message handlers, add machines... easy. Virtually no license costs. With SQL server it is exactly opposite. It now appears to me that using Service Broker for messaging is like using an expensive car to plow potato field. It is much better for other things.