如果答案是“多个”,那么在DNS轮询时它是否达到Session Stickiness？
解决方法
选择的方法取决于所采用的负载平衡方式,以及后端存储的可用性/容量：
仅存储在cookie中的会话信息：会话信息(不仅仅是会话标识符)存储在用户的cookie中.例如,用户的cookie可能包含其购物篮的内容.为了防止用户篡改会话数据,可以与cookie一起提供HMAC.此方法可能最不适合大多数应用程序：
>不需要后端存储
>用户不需要每次都使用同一台计算机,因此可以使用DNS负载平衡
>从数据库计算机检索会话信息没有与之相关的延迟(因为它提供了HTTP请求).如果您的站点由不同大洲的计算机负载平衡,则非常有用.
>可以存储在会话中的数据量有限(按4K cookie大小限制)
>如果用户无法查看其会话内容,则必须使用加密
>必须使用HMAC(或类似的)来防止用户篡改会话数据
>由于会话数据不是存储在服务器端,因此开发人员调试起来比较困难
负载均衡器始终将用户定向到同一台机器：许多负载均衡器可以设置自己的会话cookie,指示用户正在向哪台后端机器发出请求,并在将来将它们引导到该机器.由于用户始终定向到同一台计算机,因此不需要在多台计算机之间共享会话.在某些情况下这可能会很好：
>现有应用程序的会话处理可能不需要更改为多机器感知
>存储会话不需要共享数据库系统(或类似系统),可能会提高可靠性,但代价是复杂性
>一台后端机器将关闭所有启动的用户会话.
>让机器停止服务更加困难.在机器关闭之前,应允许在机器上具有会话以进行维护的用户完成其任务.为了支持这一点,Web负载平衡器可能具有将请求“消耗”到某个后端计算机的功能.
共享后端数据库或键/值存储：会话信息存储在后端数据库中,所有Web服务器都可以访问该数据库进行查询和更新.用户的浏览器存储包含指向会话信息的标识符(例如会话ID)的cookie.这可能是三者中最干净的方法：
>用户永远不需要暴露于存储的会话信息.
>用户不需要每次都使用同一台计算机,因此可以使用DNS负载平衡
>一个缺点是可以在任何后端存储系统上使用的瓶颈.
>会话信息可能已过期并一致备份.
