使用数据库或 MSMQ 排队？答案

【问题标题】：Queuing using the Database or MSMQ?使用数据库或 MSMQ 排队？
【发布时间】：2011-01-30 18:00:55
【问题描述】：

我正在处理的应用程序的一部分是一个 swf，它显示了一个包含大约 80 个问题的测试。每个问题都通过 WebORB 和 ASP.NET 保存在 SQL Server 中。

如果候选人完成了测试，则需要验证会话。问题是有时 350 名考生同时完成测试，Web 服务器和 SQL Server 上的 CPU 会爆炸（同时进行 350 次验证）。

现在，我应该如何在这里实现排队？在数据库中，有一个表，其中包含每个会话的记录。一列保存状态。 1 已完成，2 已验证。

我可以通过两种方式实现排队（在我看来，也许你还有其他提议）：

现在：

最好的方法是什么？
从哪里开始验证会话的过程？在您的 global.asax (application_start) 中？作为 Windows 服务？作为在 application_start 中启动的网站根目录上的 exe？

对我来说，使用表格并查找状态为 1 的记录似乎是最简单的方法。

【问题讨论】：

【解决方案1】：

validating 是什么？在制定您的排队策略之前，我会尝试尽可能快地设置validating，包括如果尚未设置，则将其设置为基于。

【讨论】：

我已经用谷歌搜索了 set based，但我不太清楚你的意思。我已经尽可能快地进行验证（现在每个会话 500 毫秒），但如果 350 名候选人同时验证，则需要 175 秒。虽然，它是负载均衡的，所以实际上它是 350/4 秒。它可以工作，但网络服务器的 cpu 在几分钟内接近 100%。
在数据库编程方面使用“基于集合”的操作是当您发出单个数据库命令（如 UPDATE）时，它会影响您的所有行，而不是遍历每一行并执行单独的 UPDATE在各个。我在“基于数据库集的处理”上进行了谷歌搜索，这里有两篇来自顶部附近的文章：codeproject.com/KB/database/SetAndProceduralSQL.aspx 和 weblogs.sqlteam.com/jeffs/archive/2007/04/30/60192.aspx

【解决方案2】：

MSMQ 方法decouples 来自验证逻辑服务和数据库的面向 Web 的应用程序。

这带来了很多好处，其中一些：

【讨论】：

【解决方案3】：

如果您没有使用 MSMQ 的经验并且没有设置基础设施，我建议您不要这样做。当然，这可能是在 Microsoft 平台上进行排队的“正确”方式，但它不是很直接，而且有相当长的学习曲线。

创建 Windows 服务也是如此；除非您熟悉它，否则不要这样做。对于像这样的简单案例，我认为痛苦大于回报。

最简单的解决方案可能是使用该表并在您在 global.asax 中启动的后台线程上运行该进程。您可能还想创建一个管理页面，该页面可以报告有关进程的一些状态信息（待处理作业的数量等），如果由于某种原因失败，可能还需要一个重新启动进程的按钮。

【讨论】：

【解决方案4】：

我最近一直在自己调查这个问题，所以想提一下我的发现。与您的应用程序相比，数据库的位置是决定哪个选项更快的重要因素。

我测试了插入插入 100 个数据库条目所花费的时间与将完全相同的数据记录到本地 MSMQ 消息中的时间。然后，我对多次执行此测试的结果取平均值。

我发现当数据库在本地网络上时，插入一行比登录到 MSMQ 快 4 倍。

当通过良好的互联网连接访问数据库时，向数据库中插入一行比登录到 MSMQ 慢 6 倍。

所以：

本地数据库 - DB 更快，否则 MSMQ 更快。

【讨论】：

我保证这个观点，我也有同感。我尝试将 100 条记录插入到我自己建筑物的网络中的数据库中，然后我在我的笔记本电脑中创建了 Private MSMQ 并做了同样的事情。 MSMQ 花费的时间是数据库的 1.5 倍以上。我想当您有许多服务想要在同一个地方写入数据时，MSMQ 会很好。
我偶然发现了这句话：“在事务模式下，SSB 将比 MSMQ 快得多。如果让在非事务模式下运行（尽力而为、无序、交付），MSMQ 会更快”。那么......是否可以指定您的测试是使用事务队列还是未事务队列执行？