使用 ASP.NET 会话状态服务器（而不是 InProc）的优点和缺点？
在我开始使用会话状态服务器以使会话状态在我的应用程序中比 InProc 状态更加健壮之前，我想找到一个优缺点列表以进行评估。
更新 1：还有关于幸存的应用程序池回收吗？
更新 2：会话的持续时间及其结局如何？
Before I start using Session State server for the benefit of making session state more robust in my apps compared to InProc state, I'd like to find a list of Pros and Cons for evaluation.
Update 1: Also about surviving application pool recycles?
Update 2: What about longevity of sessions and their endings?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
以下是 Rob Howard 的 ASP 对三种选项优缺点的规范分析。 NET 会话状态文章：
进程外（又名“StateServer”）和 SQL-Server 选项都可以在 Web 应用程序重新启动（包括应用程序池循环）后继续存在，并且都可以使会话数据可供集群/场中的多个服务器使用。
最后，这可能是不言而喻的，但基本的进程内设置是最容易配置的，这在许多环境中都是有意义的“专业”。
Tim Sneath 的ASP.NET 会话状态：架构和性能注意事项 添加了一些附加信息，有关会话状态模式的 MSDN 主题 是可靠、最新的来源。
Here's the canonical analysis of the pros and cons of your three options, from Rob Howard's ASP.NET Session State article:
The out-of-process (aka "StateServer") and SQL-Server options both survive web application restarts (including application pool cycling) and both make session data available to multiple servers in a cluster / farm.
Finally, it may go without saying, but the basic in-process setup is the easiest to configure, which is a meaningful "pro" in many environments.
Tim Sneath's ASP.NET Session State: Architectural and Performance Considerations adds some additional information, and the MSDN topic on Session State Modes is a reliable, up-to-date source.
状态服务器是一个很棒（！）的入门选择。为什么？因为这意味着您的应用程序现在与任何进程外存储模式兼容。
如果您当前使用
InProc开发站点，并希望稍后迁移到StateServer或SqlServer，则可能会遇到序列化问题。并不总是如此，但它确实会发生。一些示例包括（有些已经提到）：
因此，最好早点解决这个问题。它只是配置更改和服务启动；繁荣！
这也意味着，如果您决定采用完全不同的会话存储路线，例如使用 Redis（分布式键/值存储）或 RavenDB（文档数据库），那么您已经排序了。
这确实是 1 分钟工作的良好投资。现在，您已准备好使用网络场、负载平衡器和您决定对其进行原型设计的任何其他会话管理系统。
State Server is a great(!) choice to get started with. Why? Because it means that your application is now compatible with any out-of-process storage modes.
If you currently develop your site with
InProcand wanted to move intoStateServerorSqlServerat a later time, you can have issues with serialization. Not always, but it is does happen.Some examples include (some already mentioned):
Therefore, its best to get this sorted out sooner rather than later. Its only a config change and a service start; Boom!
What is also means, is if you decide to go down a completely different route of session storage, such as using Redis (Distributed Key/Value Store) or RavenDB (Document Database), you are already sorted.
Its really is a good investment of 1 minute's work. You are now ready for web farms, load balancers and any other session management systems that you decide to prototype against.
我想说使用 In_Proc 的一大缺点是，如果应用程序池或域被回收，会话状态可能会丢失。这种情况随时可能发生，例如，如果服务器内存不足等。我个人从不依赖 In_Proc 会话来获取您不想丢失的任何内容。我花了几个小时调试偶尔出现问题的站点，结果发现这是因为服务器资源回收率低而导致会话状态丢失（当然，会话中存储的内容越多，服务器资源就越少）。请记住，如果它可能出错，那么它可能会在某个时候出错！
这就是为什么我现在通常使用状态服务器来处理无关紧要的会话数据，我发现的唯一真正的缺点是您需要将类标记为可序列化，但这通常也很慢，但在大多数情况下可以忽略不计。
IIS MSDN 博客上有一篇关于此的好文章。
I'd say one of the big disadvantages of using In_Proc is that session state can be lost if the app pool or domain is recycled. This can happen any time, for instance if the server is low on memory etc. I personally never rely on In_Proc session for anything you don't want to lose. I've spent hours debugging sites with sporadic problems only to find it was because session state was being lost due to a server that was low on resources recycling (and, of course, the more you store in session the lower the more server resources you use up. Remember, if it can go wrong then it probably will go wrong at some point!
That's why I now normally use State Server for anything but trivial session data. The only real disadvantage I've found is you need to mark classes as serializable, but this is usually trivial. It's also a bit slower, too, but that is negligible in most cases.
There's a good article about this on the IIS MSDN blog.
优点：
1. 可以跨机器访问相同的会话状态。
2. 重新加载app_pool后，可以使用相同的会话状态。
缺点：
1. 比进程模式慢。
2. 会话状态中的所有对象都必须是可序列化的。
Advantages:
1. You can access the same session state across machines.
2. Same session state is available after reloading the app_pool.
Disadvantages:
1. Slower than in process mode.
2. All objects in the session state have to be serializable.
ASP.NET 中会话的缺点
每个变量都存储为对象。这意味着在读取会话变量时需要将 Object 转换为某种类型。
除此之外，如果session为空，则Object将为null。在读取会话变量之前，您需要检查它是否为空。即使变量之前已初始化，它也可能为 null，因为会话已过期。尝试使用空会话值可能会返回异常。如果会话变量的值为空，通常的做法是使用一些默认值而不是无意义的空。如果 value 不为 null，则必须将其转换为适当的类型，因为所有会话变量都是对象类型。当做所有这些事情时，你应该注意避免硬编码。有关以可扩展和可维护的方式读写会话变量的更多信息，您可以阅读如何写入、读取和删除会话状态变量教程。
变量名称是字符串类型。如果您对变量的名称进行硬编码，则可以选择在某处犯类型错误。问题是，如果您尝试读取不存在的会话变量，ASP.NET 将不会返回任何异常或警告。它只会创建具有错误名称且具有空值的新变量。这些类型的错误可能很难发现。
会话数据不应用于存储敏感数据。恶意用户有可能获得常规访问者的会话 ID。如果会话状态用于存储诸如“是否允许访问管理区域”之类的信息，攻击者就可以查看网站的敏感数据、其他人的私人数据、编辑数据库、删除内容等。
如果 InProc使用InProc模式，Session很容易耗尽所有服务器资源，从而降低网站性能。
StateServer
SQL Server 是所有模式中最可靠的。如果 ASP.NET 重新启动，会话数据将完好无损，而且如果 SQL Server 重新启动，会话数据也将完好无损。
SQL Server 也是最具可扩展性的选项。
SQL Server 通常可用于共享托管场景
自定义模式
您可以完全控制会话。甚至可以创建自定义会话 ID。
您可以支持不同的数据源。这对于在其他数据库（如 Oracle、MySQL、MS Access 等）上存储会话数据可能很有用。
有关任何其他详细信息，您可以 单击此处查看 ASP.NET 会话状态优势。希望我的回答对你有帮助。！ :)
Disadvantages of Sessions in ASP.NET
Every variable is stored as Object. That means you need to convert Object to certain type when read session variable.
In addition to this, if session is empty, Object will be null. Before reading session variable, you need to check it for null. Even if variable is initialized before, it could be null because session is expired. An attempt to use null session value could return an exception. If value of session variable is null, common practice is to use some default value instead of meaningless null. If value is not null, you must convert it to appropriate type because all session variables are type of object. When do all this things, you should pay attention to avoid hard coding. More about reading and writing of session variables on scalable and maintainable way you can read in How To Write, Read and Delete Session State Variables tutorial.
Variable name is type of string. If you hard code name of the variable, there is an option to make type mistake somewhere. The problem is, if you try to read session variable that doesn't exist, ASP.NET will not return any exception or warning. It will simply create new variable with wrong name which has null value. These types of errors could be hard to find.
Session data should not be used for storing of sensitive data. There is a possibility that malicious user obtain regular visitor's session id. If session state is used to store information like: "allow access to administration area or not" or something like that, attacker could see website's sensitive data, other's private data, edit database, delete content etc.
If InProc mode is used, sessions easily exhaust all server resources and thus decrease website performances.
StateServer
SQL Server is most reliable of all modes. Session data are intact if ASP.NET restarts, but also if SQL Server restarts.
SQL Server is also most scalable option.
SQL Server is often available in shared hosting scenario
Custom mode
You have complete control over sessions. It is possible to create even custom session id.
You can support different data sources. That could be useful to store session data on other database, like Oracle, MySQL, MS Access etc.
for any other details you can click here to view ASP.NET Session state advantages. hope my answer helped you.! :)
另一个缺点是，如果您在服务器场中使用 1 个远程状态服务器，则可能会出现单点故障。即使不是一个农场，在我看来，为了生存 app_pool ，它仍然值得在本地运行。我们陷入了可序列化的部分，所以一定要注意这一点。
另外，请密切关注 Windows Server AppFabric 的发布，因为它将有一个复制/分布式状态服务器替代品。预计 RTM 将于 1H2010 进行。
1 other disadvantage is you probably will have a single point of failure if you do 1 remote state-server across a farm. Even if not a farm, its still worth running locally just to survive app_pool IMO. We got caught up on the serializable part, so do watch that.
Also, keep an eye out for Windows Server AppFabric to release, as it will have a replicated / distributed state server replacement. Supposedly RTM in 1H2010.