这个关于允许每个会话并发请求的答案很棒，但它缺少一些重要的细节:

控件中允许每个会话并发请求的设置 更新的ASP .NET会话状态模块 Microsoft.AspNet.SessionState.SessionStateModuleAsync。这个设置是 支持任何可以使用此模块的提供者。 年长的 sessionstate模块System.Web.SessionState.SessionStateModule 不支持这个。 确保会话状态的使用是线程安全的或 会话中可能出现并发问题

摘要以启用此功能:

允许并发请求:

<appSettings>
    <add key="aspnet:AllowConcurrentRequestsPerSession" value="true"/>
</appSettings>

确保使用更新的会话状态模块:

<system.webServer>
  <modules>
    <!-- remove the existing Session state module -->
    <remove name="Session" />
    <add name="Session" preCondition="integratedMode" type="Microsoft.AspNet.SessionState.SessionStateModuleAsync, Microsoft.AspNet.SessionState.SessionStateModule, Version=1.1.0.0, Culture=neutral" />
  </modules>
</system.webServer>

对于ASPNET MVC，我们做了以下工作:

缺省情况下，设置SessionStateBehavior。通过重写DefaultControllerFactory对所有控制器的动作进行只读 在需要写入会话状态的控制器动作上，用属性标记将其设置为SessionStateBehavior。要求

创建自定义ControllerFactory并覆盖GetControllerSessionBehavior。

    protected override SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, Type controllerType)
    {
        var DefaultSessionStateBehaviour = SessionStateBehaviour.ReadOnly;

        if (controllerType == null)
            return DefaultSessionStateBehaviour;

        var isRequireSessionWrite =
            controllerType.GetCustomAttributes<AcquireSessionLock>(inherit: true).FirstOrDefault() != null;

        if (isRequireSessionWrite)
            return SessionStateBehavior.Required;

        var actionName = requestContext.RouteData.Values["action"].ToString();
        MethodInfo actionMethodInfo;

        try
        {
            actionMethodInfo = controllerType.GetMethod(actionName, BindingFlags.IgnoreCase | BindingFlags.Public | BindingFlags.Instance);
        }
        catch (AmbiguousMatchException)
        {
            var httpRequestTypeAttr = GetHttpRequestTypeAttr(requestContext.HttpContext.Request.HttpMethod);

            actionMethodInfo =
                controllerType.GetMethods().FirstOrDefault(
                    mi => mi.Name.Equals(actionName, StringComparison.CurrentCultureIgnoreCase) && mi.GetCustomAttributes(httpRequestTypeAttr, false).Length > 0);
        }

        if (actionMethodInfo == null)
            return DefaultSessionStateBehaviour;

        isRequireSessionWrite = actionMethodInfo.GetCustomAttributes<AcquireSessionLock>(inherit: false).FirstOrDefault() != null;

         return isRequireSessionWrite ? SessionStateBehavior.Required : DefaultSessionStateBehaviour;
    }

    private static Type GetHttpRequestTypeAttr(string httpMethod) 
    {
        switch (httpMethod)
        {
            case "GET":
                return typeof(HttpGetAttribute);
            case "POST":
                return typeof(HttpPostAttribute);
            case "PUT":
                return typeof(HttpPutAttribute);
            case "DELETE":
                return typeof(HttpDeleteAttribute);
            case "HEAD":
                return typeof(HttpHeadAttribute);
            case "PATCH":
                return typeof(HttpPatchAttribute);
            case "OPTIONS":
                return typeof(HttpOptionsAttribute);
        }

        throw new NotSupportedException("unable to determine http method");
    }

AcquireSessionLockAttribute

[AttributeUsage(AttributeTargets.Method)]
public sealed class AcquireSessionLock : Attribute
{ }

在global.asax.cs中连接创建的控制器工厂

ControllerBuilder.Current.SetControllerFactory(typeof(DefaultReadOnlySessionStateControllerFactory));

现在，我们可以在一个Controller中同时拥有只读和读写会话状态。

public class TestController : Controller 
{
    [AcquireSessionLock]
    public ActionResult WriteSession()
    {
        var timeNow = DateTimeOffset.UtcNow.ToString();
        Session["key"] = timeNow;
        return Json(timeNow, JsonRequestBehavior.AllowGet);
    }

    public ActionResult ReadSession()
    {
        var timeNow = Session["key"];
        return Json(timeNow ?? "empty", JsonRequestBehavior.AllowGet);
    }
}

注意:ASPNET会话状态即使在只读状态下仍然可以被写入 模式，不会抛出任何形式的异常(它只是不锁定 保证一致性)，所以我们必须小心地在控制器需要写入会话状态的动作中标记AcquireSessionLock。

如果您正在使用更新的Microsoft.Web。RedisSessionStateProvider(从3.0.2开始)你可以将它添加到你的web中。配置允许并发会话。

<appSettings>
    <add key="aspnet:AllowConcurrentRequestsPerSession" value="true"/>
</appSettings>

源

好的，非常感谢Joel Muller的贡献。我的最终解决方案是使用自定义SessionStateModule在这篇MSDN文章的最后详细说明:

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

这是:

非常快地实现(实际上似乎比走提供者路线更容易) 使用了很多标准的ASP。开箱即用的网络会话处理(通过SessionStateUtility类)

This has made a HUGE difference to the feeling of "snapiness" to our application. I still can't believe the custom implementation of ASP.Net Session locks the session for the whole request. This adds such a huge amount of sluggishness to websites. Judging from the amount of online research I had to do (and conversations with several really experienced ASP.Net developers), a lot of people have experienced this issue, but very few people have ever got to the bottom of the cause. Maybe I will write a letter to Scott Gu...

如果您的页面没有修改任何会话变量，您可以选择退出此锁的大部分。

<% @Page EnableSessionState="ReadOnly" %>

如果您的页面不读取任何会话变量，您可以选择完全退出该页面的锁。

<% @Page EnableSessionState="False" %>

如果没有页面使用会话变量，只需在web.config中关闭会话状态。

<sessionState mode="Off" />

我很好奇，如果“一个ThreadSafe集合”不使用锁，你认为它会做什么来成为线程安全的?

Edit: I should probably explain by what I mean by "opt out of most of this lock". Any number of read-only-session or no-session pages can be processed for a given session at the same time without blocking each other. However, a read-write-session page can't start processing until all read-only requests have completed, and while it is running it must have exclusive access to that user's session in order to maintain consistency. Locking on individual values wouldn't work, because what if one page changes a set of related values as a group? How would you ensure that other pages running at the same time would get a consistent view of the user's session variables?

如果可能的话，我建议您在设置会话变量之后尽量减少对它们的修改。这将允许您将大部分页面设置为只读会话页面，从而增加来自同一用户的多个同时请求不会相互阻塞的机会。

在尝试了所有可用选项之后，我最终编写了一个基于JWT令牌的SessionStore提供程序(会话在cookie中传递，不需要后端存储)。

http://www.drupalonwindows.com/en/content/token-sessionstate

优点:

Drop-in replacement, no changes to your code are needed Scale better than any other centralized store, as no session storage backend is needed. Faster than any other session storage, as no data needs to be retrieved from any session storage Consumes no server resources for session storage. Default non-blocking implementation: concurrent request won't block each other and hold a lock on the session Horizontally scale your application: because the session data travels with the request itself you can have multiple web heads without worrying about session sharing.