我正在组合一个简单的 asp.net Web 控件，它作为 ajax 表单发布的结果将一条记录插入到 MSQL 数据库中。
包含此控件的页面可能会在很短的时间内收到数千次点击，我担心打开数据库连接、插入记录然后关闭每个请求的连接的性能问题。
我想到的一个解决方案是让 Web 控件将消息放入 MSMQ 队列，并让服务器上的 Windows 服务定期读取队列并进行批量插入。
考虑到 Web 和数据库服务器运行在同一台机器上，这听起来是不是一种合理的架构。听起来有必要吗？
从我在数据库上读到的内容来看，使用 MSMQ 的大部分好处都与弹性而不是性能有关，所以我可能会找错树。
任何建议将不胜感激
非常感谢
皮特
以这种方式离线处理请求是处理大量请求时的常见模式。
您是否应该甚至可以这样做取决于许多因素。
主要因素是：您的调用者是否需要同步查看对其请求的响应？
我的意思是，调用者是否必须立即并且绝对确定地知道数据库是否成功提交了他们的数据作为调用响应的一部分？如果是这样，那么离线处理请求并不是一个真正的选择。
但是，如果可以向调用者发送一个响应，说明他们的请求将被离线处理（并且任何所需的响应也将离线发送），那么使用队列肯定会有益于您的整体架构。
首先受益的是前端可用性问题。
如果您在短时间内处理数千个请求，并且每个请求都由一个线程提供服务，然后该线程会离开并将数据插入数据库，那么您很可能会遇到没有可用的调度程序线程来服务传入请求的问题。
但是，通过减少 IIS 正在执行的后端工作量（写入本地队列相对于数据库调用来说真的很便宜），您还可以减少基于可用性的故障的可能性。
其次，通过使用队列，您将有一种限制后端流量的方法，因为您可以控制后端处理的吞吐量。
例如，您可以有一个单线程队列读取器进程，它将请求出列并将其处理到数据库中。如果您发现队列中有消息堆积，您可以通过托管更多实例来扩展队列阅读器服务。
这意味着您正在减少出现数据库争用问题的可能性，因为您可以随时更好地控制数据库上访问线程的数量。
因此，通过使用排队，您遭受的故障更少并且管理开销更低，这是编写良好的应用程序的标志。尤其是当您考虑在 Web 服务器上托管数据库时！
此外，您应该阅读称为CQRS的架构模式，其中一个核心原则是离线执行数据库写入。
异步架构有很多好处（正如 Hugh 所指出的），但肯定会带来更高的成本和复杂性。这应该仔细平衡。从 2 个组件（Web 应用程序和 DB）开始，您现在必须开发、维护和监控 4 个组件（Web 应用程序、DB、批处理服务、MSMQ）。您说 Web 服务器和 DB 服务器是同一台机器，考虑到您的性能要求，这很奇怪。明天您可能必须托管 Web 应用程序、批处理服务和 DB 是 3 台独立的机器。现在 MSMQ 也涉及到网络。还有一件事可能会出错。多线程批处理器也不容易，如果您必须按生成的顺序处理每条消息（至少对于给定实体）逻辑可能会变得复杂。
如果可能，测量两种解决方案并做出决定。