负载平衡需要服务器状态的长期会话
假设用户会话负载平衡到服务器#8，并且某些状态在服务器#8 上维护。用户的下一个操作需要再次路由到服务器#8，因为这是唯一具有其服务器状态的地方。是否有一个标准解决方案来维护长期会话的从用户会话到服务器编号的映射？似乎将用户会话映射到许多服务器中的特定服务器的问题应该是具有 CPU 和内存效率的标准“教科书”解决方案的常见问题。
Suppose a user's session is load balanced to server #8 and some state is maintained at server #8. The next action from user needs to be routed to server #8 again because that is the only place with his server state. Is there a standard solution to maintain this mapping from user session to server number for long lived sessions? It seems like this problem of mapping user session to a specific server among many servers should be a common problem with a standard "textbook" solution thats cpu and memory efficient.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一个简单的解决方案是将负载均衡器配置为使用粘性会话。负载均衡器会将用户会话关联到服务器 #8，然后来自同一会话的后续请求将自动转发到同一服务器（服务器 8）。
An easy solution is to configure your load balancer to use sticky sessions. the load balancer will associate a user session to Server #8, and then subsequent requests from the same session will automatically be forwarded to the same server (Server 8).
最好的解决方案是不要依赖服务器亲和性 - 它会使您的系统变得脆弱。我不会期待教科书上的答案，就像我不会期待教科书上关于如何在浴缸里玩烤面包机或如何用螺丝刀进行脑部手术的答案一样。
如果您必须有粘性路由，那么您如何实现它在很大程度上取决于您打算如何处理不可用的服务器 - 您是否对请求进行故障转移？或者只是停止处理本来发送到该服务器的请求？
我最初认为这是一个非常愚蠢的问题 - 除非您正在编写自己的代理/负载平衡器（在这种情况下您应该已经知道他的答案），否则有什么相关性，但是有可用的代理可以让您实现自己的主管。
因此最终归结为会话的哪些特征在 HTTP 请求中可见。由于 IP 地址添加器可以在流中更改，因此您可以使用的唯一实用特征是会话标识符 - 通常以 cookie 的形式实现。
The best solution is not to rely on server affinity - it makes your system fragile. I wouldn't expect a textbook answer in the same way I would not expect a textbook answer on how to play with a toaster in the bath nor how to perform brain surgery with a screwdriver.
If you must have sticky routing then how you implement it depends a lot on how you propose to deal with a server not being available - do you failover the requests? Or just stop processing requests which would have been directed to that server?
I initially thought that this was a very dumb question - what's the relevance unless you're writing your own proxy/load-balancer (in which case you should already know he answers) but there are proxies available which allow you to implement your own director.
So ultimately it boils down to what characteristics of the session are visible in the HTTP request. Since an IP adderss can change mid stream, the only practical characteristic you can use is the session idenitifier - usually implemented as a cookie.