通过MSMQ解耦Web和数据库层是必要的还是矫枉过正？

Question

我正在放置一个简单的asp.net web控件，作为一个ajax表单后的插入记录到MSQL数据库的结果。

包含此控件的页面可能会在小时间内收到数千次点击，我担心打开数据库连接，插入记录然后关闭每个请求的连接的性能问题。

已经发生在我身上的解决方案是让Web控件将消息放入MSMQ队列中，并在服务器上有一个Windows服务定期读取队列并执行批量插入。

这听起来像是一个明智的架构，因为Web和数据库服务器运行在同一台机器上。这听起来有必要吗？

从我读到的数据库中可以看出，使用MSMQ的大多数好处都是用弹性而不是表现，所以我可能会吠叫错误的树。

任何意见将通过这种方式非常衷心感谢

非常感谢

皮特离线

Answer 1

处理请求是当你正在处理一个高容量的请求为一个共同的模式。

您是否应该或甚至可以做到这一点是基于许多因素。

主要因素是：您的呼叫者是否需要同步查看对其请求的响应？

我的意思是，调用者必须立即并绝对确定地知道数据库是否成功提交其数据作为呼叫响应的一部分？如果是这样，那么脱机请求处理并不是真正的选择。

但是，如果可以接受主叫方发送的响应，说他们的请求将被脱机处理（并且任何必需的响应也会离线发送），那么使用队列将肯定有利于您的整体架构。

首先会受益的是前端可用性问题。

如果您在短时间内处理了数千个请求，并且每个请求都由一个线程提供服务，然后这些线程消失并将数据插入到数据库中，那么您很可能会遇到没有可用的调度程序线程存在服务传入的请求。

但是，通过减少IIS正在执行的后端工作量（写入本地队列相对于数据库调用而言确实很便宜），您还可以降低基于可用性故障的可能性。

其次，通过使用队列，您将具有限制后端流量的手段，因为您可以控制后端处理的吞吐量。

例如，您可能有一个单线程队列读取器进程，它会将请求出队并将其处理到数据库中。如果您发现在队列中建立了消息，则可以通过托管更多实例来扩展队列读取器服务。

这意味着，你正在减少越来越数据库争的问题，因为你有过在任一个时刻的数据库访问上的线程数量更多的控制权的可能性。

因此，通过使用排队你受苦故障少且具有较低的管理开销，这是写得很好的应用特点。特别是当你正在考虑在你的Web服务器上托管你的数据库时！

此外，您应该读一个名为CQRS的架构模式，其中一个主要任务是执行数据库脱机写入。

Answer 2

异步架构有很多好处（通过休），但肯定有一个与之相关的更大的成本和复杂性。这应该仔细平衡。从2个组件（网络应用程序和数据库），你现在必须开发，维护和监测4个组件（网络应用程序，数据库，批处理服务，MSMQ）。您说Web服务器和数据库服务器是相同的机器，根据您的性能要求，这很奇怪。明天你可能不得不托管网络应用，批量服务和数据库是3个独立的机器。现在MSMQ也涉及网络。还有一件事可能会出错。 多线程批处理器也是不容易的，如果你有处理生成它们的序列中的每个消息（至少对于给定的实体）逻辑可以变得复杂。

如果可能的措施，这两种解决方案而定。