我第一个关于堆栈溢出的问题，所以请放轻松。我有一个长时间运行的 Windows 应用程序，它不断处理 sql server 命令。我还有一个网络前端，用户偶尔使用它来更新同一个数据库。我注意到有时（取决于当时 Windows 应用程序正在处理的内容）如果用户向数据库提交某些内容，我会在服务器上收到内存不足异常。我意识到我需要更多地挖掘并优化代码。但是，我无法承受服务器宕机的后果，并期望将来我将允许越来越多的用户使用前端。我真正需要的是一个系统，它将用户请求排队（它们不是时间关键的）并在数据库准备好时处理它们。
我正在使用 SQL 2012 express。
SQL Service Broker 是不是最好的解决方案，我也研究过 MSMQ。
如果有人能指出我正确的方向，那将不胜感激。在我的搜索中，我只是发现了很多我认为不需要的东西。
干杯
【问题讨论】：
标签： sql-server msmq service-broker
这取决于您在哪里进行持久性工作和/或计算。如果您在 Windows 应用程序中进行艰苦的工作，那么使用 Service Broker 队列将不值得，因为您要做的就是从 Windows 应用程序中的 Service Broker 队列接收消息，进行计算和/或来自 Windows 应用程序的查询，然后将结果保存到数据库：由于您的数据库已经处于内存压力之下，这似乎是不必要的额外负载，因为您可以轻松地从 MSMQ（或任何其他@ 987654321@technology)。
但是，如果您在数据库中完成所有工作，并且您的 Windows 应用程序仅充当编组服务 - 例如，接收请求并将其转交给存储过程以执行操作 - 那么 Service Broker 队列可能值得使用：因为它们已经在数据库的上下文中运行，它们可以非常有效地持久化和查询数据。
您还需要考虑故障模式，具体取决于您是否能承受丢失任何消息的代价。为了确保消息在 MSMQ 中的持久性，您 have to use Transactional Messaging：Service Broker 在事务队列处理方面比 MSMQ 更有效（因为它具有内置的事务支持，不像 MSMQ 必须使用 DTC，这会增加开销） - 但如果您的消息少，这可能不是问题。
【讨论】：