如何跨多个 Web 服务器维护状态？
我可以将多个 Web 服务器连接到 SQL Server 群集并仍然维护用户会话吗？
我想过各种方法。 Microsoft 站点建议的一种方法是使用response.redirect 到“正确”的服务器。虽然我可以理解这样做的原因，但这似乎有点短视。
如果负载均衡器将您发送到当前压力最小的服务器，那么作为开发人员，您肯定应该尊重这一点吗？
在这种情况下有什么最佳实践可以遵循吗？如果是这样，我将很高兴知道它们是什么以及对使用它们的优点/缺点的任何见解。
Can I have multiple web servers hooked up to a SQL Server cluster and still maintain a user's session?
I've thought of various approaches. The one suggested by the Microsoft site is to use response.redirect to the "correct" server. While I can understand the reasoning for this, it seems kind of short sighted.
If the load balancer is sending you to the server currently under the least strain, surely as a developer you should honor that?
Are there any best practices to follow in this instance? If so, I would appreciate knowing what they are and any insights into the pros/cons of using them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一些选项：
负载均衡器可以配置为具有粘性会话。确保您的应用程序会话超时小于负载均衡器，否则您会遇到不可预测的结果。
您可以使用指定的状态服务器来处理会话。那么他们在哪里被LB弹回就不再重要了。
您可以使用 SQL Server 来管理会话。
在服务器故障上检查这一点。
https://serverfault.com/questions/19717/load-平衡 iis 服务器与 asp-net-inproc-session
Some options:
The load balancer can be configured to have sticky sessions. Make sure your app session timeout is less than the load balancers or you'll get bounced around with unpredictable results.
You can use a designated state server to handle session. Then it won't matter where they get bounced by the LB.
You can use SQL server to manage session.
Check this on serverfault.
https://serverfault.com/questions/19717/load-balanced-iis-servers-with-asp-net-inproc-session
我在这里引用了我的 Java 应用服务器经验，其中一些服务器具有非常复杂的平衡算法。
一个合理的一般假设是“会话亲和性”优于平衡每个请求。如果我们为每个用户分配初始请求，并具有一定程度的工作负载知识（甚至是随机的），并且用户数量来来去去，我们最终会得到合理的行为。请记住，我们的目标是为每个用户提供良好的体验，而不是最终获得均匀使用的服务器！
如果服务器发生故障，我们可以看到我们的请求移动到其他地方，并且我们期望看到我们的会话被转移。有很多方法可以实现这一点（数据库中的会话、通过高速消息传递传播的会话状态......）。
I'm taking here from my experience of Java App Servers, some with very sophisticated balancing algorithms.
A reasonable general assumption is that "Session Affinity" is preferable to balancing every request. If we allocate the initial request for each user with some level of work-load knowledge (or even on a random basis) and the population comes and goes them we do end up with a reasonable behaviours. Remember that the objective is to give each user a good experience not to end up with evenly used servers!
In the event of a server failing we can then see our requests move eleswhere and we expect to see our session transfered. Lots of way to achieve that (session in DB, session state propogated via high speed messaging ...).
这可能不是您正在寻找的答案，但是您可以消除对会话状态的需求吗？我们竭尽全力对页面本身的请求之间可能需要的任何内容进行编码。这样，我就不必担心农场的状态或可扩展性问题，因为必须保留可能永远不会回来的人所拥有的东西。
This isn't probably the answer you're looking for, but can you eliminate the NEED for session state? We've gone to great lengths to encode whatever we might need between requests in the page itself. That way I have no concern for state across a farm or scalability issues with having to hang onto something owned by someone who might never come back.
虽然您可以在负载均衡器中使用“粘性”会话，但更好的方法是让您的会话使用状态服务器而不是 InProc。那时，所有网络服务器都可以指向同一状态服务器并共享会话。
http://msdn.microsoft.com/en-us/library/ms972429。 aspx MSDN 关于这个主题有很多话要说：D
更新：
状态服务器是 Windows 服务器盒子上的一项服务，但是它会产生单点故障。
此外，您可以指定 SQL Server 会话的序列化，如果您进行了操作，则不会出现单点故障。
我不确定状态服务器的工作负载有多“重”，其他人有任何指标吗？
While you could use "sticky" sessions in your load balancer, a more optimal path is to have your Session use a State Server instead of InProc. At that point, all of your webservers can point to the same state server and share session.
http://msdn.microsoft.com/en-us/library/ms972429.aspx MSDN has plenty to say on the subject :D
UPDATE:
The State Server is a service on your windows server boxes, but yeah it produces a single point of failure.
Additionally, you could specify serialization of the session to a SQL Server, which wouldn't be a single point of failure if you had it farmed.
I'm not sure of how "heavy" the workload is for a state server, does anyone else have any metrics?