优化每分钟有大量数据库请求的应用程序答案

【问题标题】：Optimize the application with huge number of database requests per minute优化每分钟有大量数据库请求的应用程序
【发布时间】：2015-06-14 08:29:50
【问题描述】：

我必须在我的应用程序中向最终用户提供free demo 的一些服务。免费演示可以是30 mins, 1 hours, 5 hours 等（predefined time），仅限新用户一次。

用户也可以部分地消耗这些时间。就像在 30 分钟的免费演示中一样，他们可以使用今天的 10 分钟、明天的 15 分钟和第二天的剩余时间等。现在，如果用户选择 30 分钟的免费演示并登录并使用该服务。我可以通过他的开始时间和结束时间限制用户 30 分钟。如果开始和结束时间的总和等于 30 分钟，我可以将它们发送到付款页面。

现在问题出现在一些不确定的情况下，例如如果用户在活动会话期间关闭浏览器或他们的互联网停止工作或其他任何事情。在此，由于缺少 endtime，我无法计算他们消耗的时间。

场景可能如下所示（30 分钟演示）。

UserID  StartTime           EndTime             Consumed(mins)
10      09-04-2015 10:00    09-04-2015 10:10        10
10      10-04-2015 05:00    10-04-2015 05:04        4
10      11-04-2015 07:46    11-04-2015 07:56        10
10      11-04-2015 10:00    // Browser closed or any uncertain condition
10      11-04-2015 11:00    // How to restrict user to use actual 30 mins because I do not have EndTime in above row to calculate Consumed mins.

我可能同时有超过 100000 个用户使用我们的服务，所以我正在为此寻找一个有效的解决方案。

据我了解，我可以创建一个单独的作业来检查用户的 LastActiviteTime，并在此基础上更新他们在数据库中的 Consumed(mins)。该作业将每分钟执行一次，另一方面，每个会话用户的浏览器都会更新数据库中的LastActiveTime。

这可以解决我的问题，但由于每分钟有大量数据库请求，我不太确定我的应用程序的性能。

【问题讨论】：

这是什么服务？用户在使用您的服务时是否与服务器交互？
是的，用户与服务器交互，我们提供翻译类服务。

标签： .net sql-server performance architecture sql-server-performance

【解决方案1】：

如果用户正在与您的服务交互，则将这些交互实例用作最后使用时间，如果您没有结束时间时需要识别时间，则使用最后交互时间作为会话结束时间。

最简单的方法是在您显示为 lastInteractionTime 的表中再添加一列。如果没有结束时间，则使用 lastInteractionTime 来计算消耗的时间。

【讨论】：

这会增加每次活动的数据库命中率并可能导致服务器崩溃？
不这么认为。取决于如何优化它。您不是已经在为您的服务请求进行任何类型的日志记录了吗？是的，正如 Plamen 所提到的，您需要决定哪个选项是值得的。

【解决方案2】：

我建议进行性能测试，以评估对数据库的影响，使其略高于预期的最大负载。然后，根据结果，您可能会考虑使用像 RavenDB 这样的 NoSQL 解决方案来保存使用数据。 NoSQL 可以创造奇迹，非常适合此类问题。

当然，您可以使用预定的客户端脚本和 AJAX 来执行此操作，正如 Rolwin C 已经建议的那样。请记住，即使恶意用户的方式存在一些障碍，这种方法总是存在一定程度的风险。因此，请查看您的情况是否可以接受这种风险，因为它可以大大减轻数据库服务器的负担。

【讨论】：

应用程序已经建立并运行，我只需要向它添加这个功能。关系数据库（Sql Server 2012）正在使用，我无法将其更改为 NoSQL。
我建议在现有的关系数据库之外使用 NoSQL。在理想的世界中，这将是一个不错的选择。但是，当然，这取决于您的情况是否值得付出努力。无论如何，我仍然认为你应该做一个性能测试——你可能对数据库没有问题。

【解决方案3】：

您可能还可以使用 JavaScript 通过客户端脚本进行开始、结束时间验证，并将开始时间、结束时间存储在浏览器 cookie 中并运行及时脚本（每分钟执行一次的 java 脚本），因此如果验证失败客户端本身你不需要在服务器（数据库）端验证它，这样就可以减少很多用户对数据库的查询。

【讨论】：

但是如果用户在两者之间关闭它的浏览器呢
您每分钟运行的 javascript 也应该每分钟更新 cookie 中的 LastActive 时间。因此，每当用户关闭浏览器并重新打开它时，您都可以使用这个 LastActive 时间 - starttime 进行comaprision
如果用户下次在不同的浏览器中打开应用程序或清除cookies来欺骗应用程序。
在这种情况下，您仍然拥有服务器端数据库验证权.. 客户端验证不是服务器端数据库验证的替代方案，它只是降低服务器端验证次数的一种方法要求。您仍然必须保持服务器端数据库验证。
假设每 10 分钟，我使用脚本 (js) 发出数据库请求以更新数据库。现在在一种情况下，在 db 命中前 10 秒，用户关闭浏览器或清除 cookie，在这种情况下，用户基本上欺骗了服务器 9 分 50 秒的使用时间。