负载平衡环境中 WCF 服务之间的 MSMQ
我正在考虑在基于一堆 WCF 服务的产品中添加队列功能。我读过一些有关 MSMQ 的内容，首先我认为这就是我所需要的，但我不确定，并且正在考虑将队列放入数据库表中。我想知道这里有人是否得到了关于该走哪条路的反馈。
基本上我计划有一个通过 http 调用的门面 WCF 服务。外观服务应该只将所有传入消息写入队列，以便对调用系统做出快速响应。然后，队列中的消息应由另一个组件（WCF 服务或 Windows 服务）处理，具体取决于我对队列的选择。
该产品在具有 2 到 n 个 Web 服务器的负载平衡环境中运行。
我正在考虑的选项和我遇到的问题是：
- 让外观 WCF 写入 MSMQ，然后让另一个 WCF 服务从此队列中读取数据来处理消息。从我读到的内容来看，我对这种替代方案没有信心，因为它在负载平衡的环境中如何工作。
1A。 MSMQ 应放置在哪里？每个网络服务器上都有一个？一个在单独的服务器上？多个在单独的服务器上？ （不考虑冗余的需要，并且在极少数情况下数据可能会丢失并重新发送）
1B。如果我想要系统冗余，设计会受到什么影响？我希望能够丢失持有 MSMQ 的服务器（它再也不会上线）而不会丢失该队列中的数据。根据我所读到的有关 MSMQ 的内容，我只能选择将 MSMQ 放置在 Windows 集群上。这是正确的吗？ （我想避免为此使用 Windows 集群）。
- 第二种设计替代方案是让门面 WCF 服务将队列写入数据库。然后有两个或多个Windows服务来做队列的处理。我对这个替代方案没有任何疑问。如果您想知道为什么我不选择这个，因为它对我来说似乎更简单，那么这是因为我想构建这个而不向解决方案引入任何 Windows 服务，我相信 MSMQ 具有我不想要的功能我自己编写代码，我也对使用 MSMQ 感到好奇，因为我以前从未使用过它。
此致 哈坎
I'm thinking of adding a queue function in a product based on a bunch of WCF services. I've read some about MSMQ, first I thought that was what I needed but I'm not sure and are considering to just put the queue in a database table. I wonder if somone here got some feedback on which way to go.
Basicly I'm planning to have a facade WCF service called over http. The facade service should only write all incoming messages to a queue to give a fast response to the calling system. The messages in the queue should then be processed by another component, either a WCF service or a Windows service depending om my choice of queue.
The product is running in a load balanced enviroment with 2 to n web servers.
The options I'm considering and the questions I got are:
- To let the facade WCF write to a MSMQ and then have anothther WCF service reading from this queue to do the processing of the messages. What I don't feel confident about for this alternative from what I've read is how this will work in a load balanced enviroment.
1A. Where should the MSMQ(s) be placed? One on each web server? One on a separate server? Mulitple on a separate server? (not considering need of redundance and that data in rare cases could be lost and re-sent)
1B. How it the design affected if I want the system redundant? I'd like to be alble to lose a server (it never comes up online again) holding the MSMQ without losing the data in that queue. From what I've read about MSMQ that leaves me to the only option of placing the MSMQ on a windows cluster. Is that correct? (I'd like to avoid using a windows cluster fo this).
- The second design alternative is to let the facade WCF service write the queue to a database. Then have two or more Windows services to do the processing of the queue. I don't have any questions on this alternative. If you wonder why I don't pick this one as it seems simpler to me then it is because I'd like to build this not introducing any windows services to the solution, that I beleive the MSMQ got functionality I don't want to code myself and I'm also curious about using MSMQ as I've never used it before.
Best Regards
Håkan
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好的，所以您没有将 WCF 与 MSMQ 集成一起使用，而是使用 WCF 创建 MSMQ 消息作为最终产品。这将事情简化为“如何对 MSMQ 进行负载平衡？”
您使用的安排取决于最适合您的安排。
您可以有多个网络服务器将消息发送到中央计算机上的远程队列。
相反，您可以让网络服务器将消息放入本地队列中，并由中央机器轮询队列中是否有新到达的消息。
您不需要对 MSMQ 进行集群来使其具有弹性。相反，您可以使代码具有弹性，以便使用死信队列、事务队列、日志记录等来处理丢失的消息。硬件集群是一个简单的选择:-)
讨论
消息和负载平衡
OK, so you're not using WCF with MSMQ integration, you're using WCF to create MSMQ messages as an end-product. That simplifies things to "how do I load balance MSMQ?"
The arrangement you use is based on what works best for you.
You could have multiple webservers sending messages to a remote queue on a central machine.
Instead you could have a webservers putting messages in local queues with a central machine polling the queues for new arrivals.
You don't need to cluster MSMQ to make it resilient. You can instead make your code resilient so that it copes with lost messages using dead letter queues, transactional queues, journaling, and so on. Hardware clustering is the easy option :-)
discussion
messages and load balancing
在阅读了有关该主题的更多内容后，我决定不使用 MSMQ。看来我真的没有理由走这条路了。我需要这是非事务性的，据我所知，任何日记或死信技术都无法帮助我满足我的冗余要求。
我的所有组件大部分时间都会在线（当遇到访问问题时，每年可能有几个小时）。
MSQM 只会增加令人兴奋的解决方案的复杂性，这是另一种技术，也许还需要跟踪另一台服务器。
为了获得完全冗余以防止 MSMQ 中的数据丢失，我需要一个 Windows 集群或实现向多个相同队列的发送/接收。我不想做其中任何一个。
所有这些导致我在接收应用程序前面使用 WCF 外观，接受写入数据库队列的 http 调用。该数据库已受到保护，不会丢失数据。该队列将由包含所有繁重业务逻辑的 Windows Servce 的多个活动实例进行轮询。由于进程优先级较低，这些服务可以托管在负载平衡 Web 应用程序使用的现有节点上。如果我有时间使用 MSMQ 或者如果我在应用程序中出于其他原因需要它，我可能会改变我的决定。
After reading some more on the subjet I haver decided to not use MSMQ. It seems like I really got no reason to go down this road. I need this to be non-transactional and as I understand it none of the journaling or dead letter techniques will help me with my redundancy requirement.
All my components will be online most of the time (maybe a couple of hours per year when they got access problems).
The MSQM will only add complexity to the exciting solution, another technique and maybe another server to keep track of.
To get full redundance to prevent data loss in MSMQ I will need a windows cluster or implement send/recieve to multiple identical queues. I don't want to do either of those.
All this lead me to front my recieving application with a WCF facade accepting http calls writing to a database queue. This database is already protected from data loss. The queue will be polled by muliple active instances of a Windows Servce containing all the heavy business logic. With low process priority these services could be hosted on the already existing nodes used by the load balaced web application. If I got time to use MSMQ or if I needed it for another reason in my application I might change my decision.