问题
I have an application that consists of three parts:
- a front-end web shop for end-users and business partners
- an order-management system to handle those orders
- a technical database system to handle all the technical details of those products and services ordered
Today, those systems (which are on separate servers and being developed by separate teams) interoperate using WCF webservices.
This setup up works fine - as long as all servers are up. Which they're not - not always, anyway.
So I've started looking at using either MSMQ or SQL Server Service Broker to handle the communication between those systems - at least when it comes to the web shop storing an order into the order management system, or the order management system sending the technical data to the tech database system.
I'm hoping to achieve more reliability in the entire system - users can still place orders and those won't get lost, even if the order management backend is temporarily unavailable.
But the big question is: MSMQ or Service Broker?? All three systems are Windows- and .NET based, and use SQL Server already - on three separate servers.
Does anyone have some solid, real-world facts that speak for (or against) one of those two technologies? What are your real-life experiences with those two sets of technologies? Pros and cons. If you could start from scratch - which one would you choose? Or would you pick something else (what?) entirely?
回答1:
I have used both, in different situations, equally well. My preference is really pretty basic: use SQL Service Broker if message sending event is triggered from a database event; Use message queue if event is in code. That preference is based just that it easier to setup on the same platform that will trigger the event.
来源：https://stackoverflow.com/questions/3963362/msmq-vs-sql-server-service-broker