domain-name-system – 如何在多个Web服务器上实现会话粘性？

概述StackOverflow / ServerFault有多少个Web服务器？ 如果答案是“多个”,那么在DNS轮询时它是否达到Session Stickiness？ 大型网站可能跨多台机器“负载均衡”.在许多负载平衡设置中,用户可能在会话期间命中任何后端计算机.因此,存在许多允许许多机器共享用户会话的方法. 选择的方法取决于所采用的负载平衡方式,以及后端存储的可用性/容量： 仅存储在cookie中 StackOverflow / ServerFault有多少个Web服务器？

如果答案是“多个”,那么在DNS轮询时它是否达到Session Stickiness？

解决方法 大型网站可能跨多台机器“负载均衡”.在许多负载平衡设置中,用户可能在会话期间命中任何后端计算机.因此,存在许多允许许多机器共享用户会话的方法.

选择的方法取决于所采用的负载平衡方式,以及后端存储的可用性/容量：

仅存储在cookie中的会话信息：会话信息(不仅仅是会话标识符)存储在用户的cookie中.例如,用户的cookie可能包含其购物篮的内容.为了防止用户篡改会话数据,可以与cookie一起提供HMAC.此方法可能最不适合大多数应用程序：

>不需要后端存储
>用户不需要每次都使用同一台计算机,因此可以使用DNS负载平衡
>从数据库计算机检索会话信息没有与之相关的延迟(因为它提供了http请求).如果您的站点由不同大洲的计算机负载平衡,则非常有用.
>可以存储在会话中的数据量有限(按4K cookie大小限制)
>如果用户无法查看其会话内容,则必须使用加密
>必须使用HMAC(或类似的)来防止用户篡改会话数据
>由于会话数据不是存储在服务器端,因此开发人员调试起来比较困难

负载均衡器始终将用户定向到同一台机器：许多负载均衡器可以设置自己的会话cookie,指示用户正在向哪台后端机器发出请求,并在将来将它们引导到该机器.由于用户始终定向到同一台计算机,因此不需要在多台计算机之间共享会话.在某些情况下这可能会很好：

>现有应用程序的会话处理可能不需要更改为多机器感知
>存储会话不需要共享数据库系统(或类似系统),可能会提高可靠性,但代价是复杂性
>一台后端机器将关闭所有启动的用户会话.
>让机器停止服务更加困难.在机器关闭之前,应允许在机器上具有会话以进行维护的用户完成其任务.为了支持这一点,Web负载平衡器可能具有将请求“消耗”到某个后端计算机的功能.

共享后端数据库或键/值存储：会话信息存储在后端数据库中,所有Web服务器都可以访问该数据库进行查询和更新.用户的浏览器存储包含指向会话信息的标识符(例如会话ID)的cookie.这可能是三者中最干净的方法：

>用户永远不需要暴露于存储的会话信息.
>用户不需要每次都使用同一台计算机,因此可以使用DNS负载平衡
>一个缺点是可以在任何后端存储系统上使用的瓶颈.
>会话信息可能已过期并一致备份.

总的来说,大多数动态Web应用程序执行许多数据库查询或键/值存储请求,因此数据库或键/值存储是会话数据的逻辑存储位置.

总结

以上是内存溢出为你收集整理的domain-name-system – 如何在多个Web服务器上实现会话粘性？全部内容，希望文章能够帮你解决domain-name-system – 如何在多个Web服务器上实现会话粘性？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。