通过MSMQ必要或矫枉过正去耦网络层和数据库层？ [英] Is decoupling web and database tiers via MSMQ necessary or overkill?
问题描述
我组建了一个简单的asp.net web控件，这是一个ajax表单提交的结果将记录插入一个MSQL数据库中。
I'm putting together a simple asp.net web control, that as the result of an ajax form post inserts a record into a MSQL database.
这可能是因为包含此控件的页将收到数以千计的命中在时间的一小空间，我很担心打开一个数据库连接，插入记录，然后关闭每个请求的连接的性能问题。
It's possible that the page containing this control will recieve many thousands of hits in a small space of time and I'm worried about the performance issue of opening a database connection, inserting the record and then closing the connection for each request.
这已发生给我一个解决方案是使Web控件地点的消息到MSMQ队列，并有一个Windows服务的服务器上定期读取队列，并做了批量插入。
A solution that has occured to me is to make the web control place a message into an MSMQ queue and have a Windows Service on the server periodically read the queue and do a batch insert.
这是否给出听起来像一个合理的架构，网络和数据库服务器在同一台机器上运行。听起来是不是必要的？
Does that sound like a sensible architecture given that the web and database servers are running on the same machine. Does it sound necessary?
这是我读过的最数据库使用MSMQ的好处在与应变能力，而不是性能做的，所以我可能会找错了树。
From what I've read on the database most of the benefits of using MSMQ are to do with resilience rather than performance, so I might be barking up the wrong tree.
任何意见将非常感激AP preciated
Any advice would be very gratefully appreciated
非常感谢
皮特
推荐答案
离线以这种方式处理的请求是当你正在处理一个高容量的要求，为一个共同的模式。
Processing requests offline in this way is a common pattern for when you are dealing with a high volume of requests.
你是否应该或者甚至能做到这一点是基于许多因素。
Whether you should or even can do this is based on a number of factors.
的主要因素是：做你的呼叫者需要看到同步他们的请求的响应？
The main factor is: do your callers need to see the response to their requests synchronously?
我的意思是不来电者必须知道，立即绝对肯定，如果数据库成功提交自己的数据作为呼叫响应的一部分？如果是这样，那么请求处理脱机是不是一个真正的选择。
What I mean is does the caller have to know, immediately and with absolute certainty, if the database successfully committed their data as part of the call response? If so, then taking request processing offline is not really an option.
不过，如果是可以接受的呼叫者可以发送话说，他们的请求将离线进行处理（以及任何需要的反应也离线发送），然后使用队列肯定有利于你的整体架构的响应。
However, if it is acceptable that callers can be sent a response saying that their request will be processed offline (and any required response also sent offline) then using a queue will definitely benefit your overall architecture.
这将受益的第一件事是前端可用性问题。
The first thing that will be benefited is front-end availability issues.
如果您正在处理数以千计的请求，在短期内，每个请求由一个线程，然后消失并插入数据到数据库服务，很可能你会遇到在没有可用的调度线程存在服务问题传入的请求。
If you are processing thousands of requests over a short period, and each request is serviced by a thread which then goes away and inserts data into a database, very likely you will run into the problem where no available dispatcher thread exists to service incoming requests.
然而，通过减少后端工作的IIS的量做（写入本地队列确实相对于数据库呼叫便宜）你也减少基于可用性失效的可能性。
However, by reducing the amount of back-end work IIS is doing (writing to a local queue is really cheap relative to a database call) you are also reducing the likelihood of availability-based failure.
其次，通过使用一队列你将有节流后端流量的手段，因为你必须在对后端处理的吞吐量控制。
Secondly by using a queue you will have a means of throttling back-end traffic, because you have control over the throughput on the back-end processing.
例如，你可以有一个单线程的队列阅读器的过程，去请求排队并处理到数据库中。如果你发现你的消息通过举办它的多个实例建立在你可以只向外扩展队列读者服务的队列。
For example, you could have a a single-threaded queue reader process which de-queues a request and processes it into a database. If you find you have messages building up in the queue you can just scale out the queue reader service by hosting more instances of it.
这是什么意思是，你得到减少数据库争用问题，因为你有过在任何一个时间对数据库访问的线程数量更多的控制权的可能性。
What this means is that you are reducing the likelihood of getting database contention issues because you have more control over the number of accessing threads on the database at any one time.
因此，通过使用排队你受苦故障少且具有较低的管理费用，这是井编写的应用程序的特点。这尤其是当你考虑你的Web服务器上托管你的数据库！
So, by using queuing you suffer fewer failures and have lower management overhead, which are the hallmarks of well written applications. This especially when you are considering hosting your database on your web server!
此外，你应该有一个架构模式的读了一个名为 CQRS ，中心负责人之一，其中的做你的数据库脱机写道。
Also, you should have a read up of an architectural pattern called CQRS, one of the central principals of which is to do your database writes offline.
这篇关于通过MSMQ必要或矫枉过正去耦网络层和数据库层？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
