linq-to-sql - 高负载页面上 LINQ To SQL 的替代方案

Question

首先，我喜欢 LINQ TO SQL。它比直接查询更容易使用。

但是，有一个很大的问题:它不能很好地处理高负载请求。我的 ASP.NET MVC 项目中有一些 Action ，每分钟调用数百次。

我曾经在那里有 LINQ to SQL，但由于请求数量巨大，LINQ TO SQL 几乎总是返回“未找到或更改行”或“X 次更新失败”。这是可以理解的。例如，我必须为每个请求增加一个值。

var stat = DB.Stats.First();
stat.Visits++;
// ....
DB.SubmitChanges();

但是当 ASP.NET 处理这些//... 指令时，存储在表中的 stats.Visits 值发生了变化。

我找到了解决方案，我创建了一个存储过程

UPDATE Stats SET Visits=Visits+1

效果很好。

不幸的是，现在我遇到越来越多这样的时刻了。而且为所有情况创建存储过程很糟糕。

所以我的问题是，如何解决这个问题？有什么替代品可以在这里工作吗？

我听说 Stackoverflow 可以与 LINQ to SQL 一起使用。而且它比我的网站加载更多。

Answer 1

这并不是 Linq to SQL 本身的问题，它是乐观并发的预期结果，Linq to SQL 默认使用它。

乐观并发意味着当你更新一条记录时，你在进行任何离线更新之前检查数据库中的当前版本与最初检索到的副本；如果它们不匹配，则报告并发冲突(“未找到或更改行”)。

这里有更详细的解释here .还有一个相当大的guide on handling concurrency errors .通常，解决方案涉及简单地捕获 ChangeConflictException 并选择解决方案，例如:

try
{
    // Make changes
    db.SubmitChanges();
}
catch (ChangeConflictException)
{
    foreach (var conflict in db.ChangeConflicts)
    {
        conflict.Resolve(RefreshMode.KeepCurrentValues);
    }
}

以上版本将用当前值覆盖数据库中的任何内容，而不管进行了哪些其他更改。有关其他可能性，请参阅 RefreshMode枚举。

您的另一个选择是完全禁用您期望可能会更新的字段的乐观并发。为此，您可以将 UpdateCheck 选项设置为 UpdateCheck.Never。这必须在现场一级完成；您无法在实体级别或全局上下文级别执行此操作。

也许我还应该提到，您没有为您要解决的特定问题选择一个非常好的设计。通过重复更新单行的单列来增加“计数器”并不是关系数据库的非常好的/适当的使用。你应该做的实际上是维护一个历史表 - 例如 Visits - 如果你真的需要非规范化计数，请在数据库本身中使用触发器来实现它。试图在没有任何数据备份的情况下在应用程序级别实现站点计数器只是自找麻烦。

使用您的应用程序将实际的数据放入您的数据库中，并让数据库处理聚合 - 这是数据库擅长的事情之一。