C# .NET 工作负载处理a la 作业队列处理示例想法？
作为我不断学习如何使应用程序更好地扩展的学习曲线的一部分，我目前正在尝试找到一个队列的方向，即作业队列或工作负载处理，无论你喜欢什么短语。
在遥远的过去，我使用过 IBM MQ/Series - 它适用于金融应用程序，但如果我记得的话，它相当重。
我知道 MSMQ，而且还听说过不少其他的。
但首先，这是我的上下文
我有一个 C#/.NET 后端 Web 应用程序，它通过 AJAX 向 Javascript（主要是 jQuery 等）前端提供数据等我遇到的情况是，某个操作涉及上传一些文件、在数据库中设置一些记录条目、向一些用户发送电子邮件等。所以我当然不想让这个过程“在线”/“真实”由于可能存在时间延迟，我确信网络服务器/数据库等的开销。
因此，考虑到我需要排队和处理的“消息”类型，会是什么（我不应该在这里简单地说我你猜！）一个好的起点？我应该使用 MSMQ 和/或 SQL 2008 服务代理程序或 ZeroMQ 之类的东西运行 - 或者我应该简单地创建自己的轻量级工作负载队列服务？
我再次意识到，在没有看到完整图片的情况下，很难提出完整的建议，但是我们非常感谢任何起点！
大卫
As part of my constant learning curve into what you can do to make apps scale better, I am currently trying to get a direction to go with queuing, i.e. job queuing or workload processing whichever phrase you like.
In the distant past I used IBM MQ/Series - it worked for a financial app but quite heavy if I remember.
I know of MSMQ, and I have also heard of quite a few others.
But first, here is my context
I have a C#/.NET back-end web app which serves data etc to a Javascript (mostly jQuery etc) front-end via AJAX calls etc. I have a situation where a certain action involves uploading some files, setting up a few record entries in the database, emailing some users etc. So of course I don't want to make this process "online"/"real-time" due to the possible time delay and I am sure the overheads on the webserver/database etc.
So given the type of "messages" that I need to queue and process, what would be (I shouldn't just say easy here I guess!) a good start point? should I run with MSMQ and/or the SQL 2008 service broker stuff, or something like ZeroMQ - or should I simply create my own lightweight workload queue service?
I realise again without seeing the full picture it is hard to make full recommendations, however any start points gratefully received!
David
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
请不要尝试自己制作！有太多的事情需要考虑，因此您很可能会比项目的其他部分花费更多的时间。
我想说选择 MSMQ，它非常容易与 WCF 一起使用，队列是事务性的，具有重试机制等，并且您可以从 MSMQ UI 中受益，以查看消息、移动消息等。
Don't try to make your own, please! There are so many things to take into account that you will spend more time on it than the rest of your project most probably.
I'd say go for MSMQ, it's very easy to use with WCF, the queues are transactional, have a retry mechanism, etc, and you benefit from the MSMQ UI to see the messages, move them and so on.