网络负载均衡场景下的会话状态
我们目前已经为站点设置了当前服务器：
- 服务器 1：管理系统和服务器 1：管理系统数据库
- 服务器 2：公共站点
- 服务器 3：公共站点
服务器 2 和 3 使用 Windows 网络负载平衡系统进行管理。它们都运行公共站点代码的副本。
这些网站严重依赖会话，因为它们需要用户登录，我的问题是：
如何保留服务器之间的状态？
公共站点的 web.config 目前看起来像这样：
<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=localhost:42424"/>
当然，这只是将“localhost”更改为我想要存储会话的 IP 的情况？我正在考虑使用数据库服务器来存储会话，所以它看起来像这样：
<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=databaseserverIP:42424"/>
这样做明智吗？
我发现了很多关于这个主题的相互矛盾的文档，并且希望任何人能够深入了解他们之前/将如何做到这一点。
另外（当我在这里时！），管理系统允许您上传文章图像。我正在考虑在服务器 2 和 3 上设置一个虚拟目录，该目录将指向管理站点上上传目录的网络共享映射，是否有任何理由不赞成这样做？
为我的无知道歉，这对我来说是未知的领域！
谢谢，肖恩
We've currently got the current server set up for a site:
- Server 1: Admin System & Database
- Server 2: Public site
- Server 3: Public Site
Server 2 and 3 are managed using the Windows Network Load Balancing system. They are both running copies of the public site code.
The sites rely heavily on sessions because they work with user logins, my question is this:
How do I retain state between servers?
The web.config for the public sites currently look like this:
<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=localhost:42424"/>
Surely it's just a case of changing "localhost" to the I.P of where I want to store the session? I'm thinking of using the Database server to store session, so it would look like this:
<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=databaseserverIP:42424"/>
Would this be wise?
I've found lots of conflicting documentation on the subject and would appreciate anyone giving an insight into how they've done it before/ would do it.
Also (while I'm here!), the admin system allows you to upload images for articles. I was thinking of setting up a virtual directory on servers 2 and 3, which would point to a network share mapping to the upload directory on the admin site, is there any reason why this would be frowned upon?
Apologies for my ignorance, this is uncharted territory for me!
Thanks, Sean
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
取决于您想要什么国家服务。
通常，在负载平衡的情况下，您会选择 SQL Server 会话或 ASP.NET 状态服务。
每个都有其优点/缺点（SQL Server Session 需要序列化/反序列化，但如果服务器发生故障，则保持状态；ASP.NET State 在服务器故障转移时不保持状态，但由于没有序列化/反序列化，速度要快得多）。
无论如何，请考虑将服务托管在单独的独立计算机上 - 这样它就不会与其他进程争夺资源。
关于这两者的讨论需要您进一步研究 - 作为您，可用性或速度是否是您的首要关注点。
请记住，如果您想在 Web 服务器（即 Webfarm）之间共享会话，则需要将每个服务器的 machineKey 设置更新为相同。
这里一篇关于 ASP.NET 会话状态（以及 machineKey）的好文章我提到的问题）。
Depends on what State Service you are wanting.
Generally in a load-balanced scenario, you'd go for SQL Server Session, or ASP.NET State service.
Each has its pro's/con's (SQL Server Session requires serialization/deserialization, but maintains state if the server falls over, ASP.NET State does not maintain state if the server fails over but is much faster due to no serialization/deserialization).
Regardless, consider hosting the service on a seperate, independant machine - so its not fighting for resources with other processes.
A discussion on the two needs further research on your part - as you whether availability or speed is your primary concern.
Keep in mind if you want to share session between web servers (ie a webfarm), you'll need to update the machineKey settings for each server to be identical.
Here's a good article on ASP.NET Session State (and the machineKey issue i mentioned).
您应该使用 SQL 数据库来存储会话。设置 mode="SqlServer" 并运行 aspnet_regsql 将会话表添加到数据库中。
此外，您还需要确保在会话中存储的任何对象都被标记为 [Serialized]
You should use a SQL database to store the session. Set the mode="SqlServer" and go run aspnet_regsql to add the session tables to your database.
Also, you'll need to make sure that any objects you are storing in the session are marked as [Serializable]
另一种需要考虑的方法是“粘性”会话。
您可以在此处将负载平衡器配置为始终将给定的“会话”定向到同一个盒子。大多数（如果不是全部）商业负载均衡器都支持这一点。基本上，他们插入自己的会话 cookie 或 http 标头，用于识别给定的用户会话。然后，该会话将始终路由到同一个盒子（除非它出现故障）。
这种方法的优点是您可以继续使用简单的会话状态，因此它简化了服务器配置和设置。
缺点是没有故障转移冗余，因为单个服务器的丢失仍然会导致其上所有会话的丢失，而且它会损害整体负载平衡性能，因为它无法以相同的方式动态调整，如果一个服务器服务器开始过载（它可以将新会话路由到另一台服务器，但必须继续将现有会话发送到同一台服务器。）
Another approach to consider is that of "sticky" sessions.
This is where you configure your load-balancers to always direct a given "session" to the same box. Most, if not all, commercial load-balancers support this. Basically they insert their own session cookie or http header that is used to identify a given user session. This session will then always be routed to the same box (unless it goes down).
The pro of this approach is you can continue to use plain session state and so it simplifies you server configuration and setup.
The cons are that you have no fail over redundancy because a loss of a single server will still result in a loss of all the sessions on it, plus it impair overall load balancing performance as it can't adjust dynamically in the same way if one server starts getting overloaded (it can route new sessions to another server, but must keep sending existing sessions to the same one.)
如果您想要可用性（即会话在任何服务器上可用，无论服务器出现故障），那么 SQL 路由是可行的方法，但您也可以查看 ScaleOut SessionServer (http://www.scaleoutsoftware.com/pages/products/scaleout-sessionserver.php)
干杯
为猫
If you want availability (ie sessions are available on any server irrespective of server failure) then the SQL route is the way to go but you could also look at ScaleOut SessionServer (http://www.scaleoutsoftware.com/pages/products/scaleout-sessionserver.php)
Cheers
The Cat