IIS 中多个工作线程的共享消息队列
我目前正在尝试将我们的新 Intranet (ASP-MVC) 与我们的寻呼机系统的 Web 前端连接起来。寻呼机系统的前端已有大约10年的历史，界面很差并且没有文档。为此，我将 Intranet 上的表单发布到服务器，然后我们的服务器将 HTTP POST 发送到寻呼服务器，模仿其自己的表单发送的内容。
在测试过载时（我们几乎同时发送了大约 10 条消息），寻呼服务器崩溃了，因为系统是一个黑匣子，我们注意到的唯一区别是并发 POST，我们至少能做的就是尝试防止这种情况发生。
我想让所有消息都进入一个队列，最多每 5-10 秒发送一次，但我不确定如何实现这一点，有人有任何建议或一些基本教程的链接来帮助我开始吗？
更新
我之前没有指定这一点，但从浏览器的角度来看，该过程应该是同步的，即网络服务器从浏览器获取http POST请求，消息被放入队列，消息是从队列中发送后，网络服务器将 http 响应发送到浏览器。这不是一个大容量服务，我预计同时请求很少见，因此响应将接近瞬时，它更多的是防止并发请求潜在问题的限制。
I'm currently trying to interface our new intranet (ASP-MVC) with the web front end of our pager system. The pager system's front end is about 10 years old, poor interface and no documentation. To do this I have the form on the intranet post to the server, our server then sends an HTTP POST to the pager server that mimics what its own form sends.
While testing this for overloading (we sent about 10 messages almost concurrently) the pager server crashed, as the system is a black box and the only difference we noticed was the concurrent POSTs the least we can do is try to prevent this happening.
I want to have all messages go into a queue that sends at most once every 5-10 seconds but I'm not sure how to implement this, does anyone have any suggestions or links to some basic tutorials to get me started please?
Update
I didn't specify this earlier but the process should be synchronous from the point of view of the browser, ie webserver gets the http POST request from the browser, message is put into the queue, message is sent from the queue, webserver sends http response to the browser. This is not a high volume service and I expect simultaneous requests to be rare so response will be near instantaneous, it is more of a throttle to prevent potential issues with concurrent requests.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
假设您不想丢失任何请求，您的队列需要是持久的。您可以汇总自己的实现并将数据放入数据库中，也可以使用 MessageQueue 作为现成的后备存储。您的 Intranet 站点将把消息推送（发送）到数据库或 MSMQ 中。您可以编写 Windows 服务或计划的控制台应用程序以从队列中读取（使用轮询），然后将数据发布到寻呼机系统。
以下是几篇关于消息队列的文章：
http://www.primaryobjects.com/CMS/Article77.aspx 和
http://msdn.microsoft.com/en-us/library /system.messaging.messagequeue.aspx
Assuming, you don't want to loose any request, your queue needs to be persistent. You can roll up your own implementation and puts the data into database or you can use MessageQueue as ready-made backing store. Your intranet site will be pushing (sending) messaged into database or MSMQ. You can write windows service or a scheduled console application to read from queue (using polling) and then post the data to your pager system.
Here are few articles to start with message queue:
http://www.primaryobjects.com/CMS/Article77.aspx and
http://msdn.microsoft.com/en-us/library/system.messaging.messagequeue.aspx
听起来像是排队消息传递的工作！ :)
Windows 上的一些选项（排名不分先后）是：
通过所有这些实现，您可以将寻呼机消息插入到队列中，然后使用工作进程从队列中弹出消息。排队并发送到下游服务。您的工作人员将控制队列的流量。
如果寻呼机服务由于某种原因出现故障，您就不会发送消息 - 它会留在队列中以再次重试。
在 google 上搜索“[在此处插入技术] 入门”，我相信您会获得足够的信息和示例代码来开始使用。
MSMQ
MSMQ 性能稳定且易于使用。它有一些开箱即用的限制，例如 4MB 消息大小和使队列高度可用（每个队列实例通常由服务器上的本地存储支持）。
如果您拥有队列的两端（发送方和接收方），则可以轻松克服 4MB 消息大小，因为您可以通过队列对消息进行分块（将大于 4MB 的消息分成更小的块并在接收方上重新组装）。
克服 HA 限制通常需要存储和集群资源方面的帮助 - 从源系统恢复消息可能比愚弄集群 MSMQ 更容易（这对我来说听起来是错误的，但这是我的经验 - 希望 MSMQ 专家在博客中介绍成功的 HA） Service Broker 是一个内置
Service Broker
于 Sql Server 中的出色的点对点队列解决方案（甚至 Sql Express 也有），它的唯一缺点是缺乏工具，这使得
Service Broker 的 配置管理变得困难。如果您有来自单个队列的多个队列使用者，这是一个不错的选择...假设 Sql Server 是 HA，这将是一个 HA 队列解决方案。
SQL
如果您愿意控制 Server，这可能是一个不错的选择。通过 T-SQL 从队列中批处理工作单元。 Service Broker 将为您处理一些事情。
如果您有来自单个队列的多个队列使用者，那么自定义 SQL 队列是一个不错的选择...这使得假设 Sql Server 是 HA 的 HA 队列解决方案成为可能。
第三方队列产品
有许多第三方队列产品可以插入此处 - 尽管它们可能不是 Windows 甚至 .NET 特定的。如果您的环境希望实现“排队即服务”，这可能是一个很好的解决方案。您可以获得许多良好的队列实现的 .NET 绑定。查看高级消息队列协议的实现，了解更多信息。
Sounds like a job for queued messaging! :)
Some options on Windows, in no particular order, are:
With all these implementations, you insert the pager message into a queue, and then use a worker process to pop the messages off the queue and send to the downstream service. Your worker will control the flow rate from the queue.
If the pager service goes down for whatever reason, you don't send the message - it gets left in the queue to be retried again.
Search the googles for "Getting Started with [Insert Technology Here]" and I'm sure you'll get enough information and sample code for you to get started.
MSMQ
MSMQ flat out rocks and is easy to work with. It has a couple of limitations out of the box such as 4MB message size and making queues highly available (each queue instance is typically backed by local storage on a server).
4MB message size can be overcome easily if you own both ends of the queue (both sender and receiver) as you can chunk your messages through the queue (break a message > 4MB into smaller chunks and reassemble on the receiver.
Overcoming the HA limitation typically takes assistance with storage and cluster resources - its probably easier to be able to recover messages from source system than fool with clustering MSMQ (this sounds wrong to me, but has been my experience - would love for MSMQ guru to blog about successful HA).
Service Broker
Service Broker is a great point to point queuing solution built into Sql Server (even Sql Express has it). Its only drawback is the lack of tooling which makes configuration management difficult.
Service Broker is a good choice if you have multiple queue consumers from a single queue...this makes for a HA queueing solution assuming Sql Server is HA.
Custom Sql Queue
This can be a good choice if your comfortable with controlling the batching of units of work out of your queue via T-SQL. Something that Service Broker will handle for you.
Custom SQL queue is a good choice if you have multiple queue consumers from a single queue...this makes for a HA queueing solution assuming Sql Server is HA.
Third Party Queueing Products
There are a number of 3rd party queueing products out there that can be inserted here - though they may not be Windows, or even .NET specific. This can be a good solution if your environment is looking to implement "queueing as a service". You can get .NET bindings for lots of good queuing implementations. Check out implementations of Advanced Message Queueing Protocol for more information.