通过 MSMQ 分离 Web 和数据库层是必要的还是矫枉过正的? [英] 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.

考虑到 Web 和数据库服务器在同一台机器上运行，这听起来像一个明智的架构吗?听起来有必要吗?

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.

非常感谢任何建议

非常感谢

皮特

推荐答案

以这种方式离线处理请求是处理大量请求时的常见模式.

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 分离 Web 和数据库层是必要的还是矫枉过正的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！