粘滞会话/会话相关性负载分stream策略的优缺点？
一种高可扩展性的方法是使用networking负载平衡来分割多个服务器之间的处理负载。
这种方法提出的一个挑战是服务器在哪里知道状态 – 将用户状态存储在“会话”中。
这个问题的一个解决scheme是“粘性会话”（aka“session affinity”），其中每个用户被分配给单个服务器，并且在整个会话期间，他/她的状态数据被专门包含在该服务器上。
“粘性会议”方法的优点和缺点是什么？ 你用它，如果是的话，你满意吗？
优点：
- 这很容易 – 不需要更改应用程序。
- 更好地利用本地RAMcaching（例如查找一次用户configuration文件，caching它，并可以在来自同一用户的后续访问中重新使用它）
缺点：
- 如果服务器closures，会话将丢失。 （请注意，这是在Web服务器本地存储会话信息的一个骗局，而不是粘滞会话本身）。 如果会话中的内容对用户（例如电子邮件草稿）或网站（例如购物车）非常重要，那么丢失一台服务器可能会非常痛苦。
- 取决于负载平衡器中的“粘性”实现，可能会导致一些服务器与其他服务器的负载不相等
- 带来一个新的服务器在线不会立即给新的服务器很多的负载 – 如果你有一个dynamic的负载平衡系统来处理峰值，粘性可能会减慢你对迅速作出反应的能力。 这就是说，这是一个angular落的情况下，真的只适用于非常大的和复杂的网站。
- 如果您的用户相对较less，但单个用户的stream量可能会淹没一台服务器（例如，使用SSL，AJAX，dynamic生成的映像，dynamic压缩等的复杂页面），则粘附可能会伤害最终用户的响应时间，因为您不将单个用户的负载均匀地分布在服务器上。 如果你有很多的并发用户，这是一个没有问题，因为你所有的服务器将被淹没！
但是，如果您必须使用服务器本地会话状态，则粘性会话绝对是一种方法 – 即使您不使用服务器本地会话状态，粘滞性在caching利用率方面也有所帮助（请参阅上文）。 您的负载平衡器应该能够查看HTTP Cookie（不仅是IP地址）来确定粘性，因为IP地址可以在单个会话期间改变（例如，在有线和无线networking之间对接笔记本电脑）。
更好的是，不要在Web服务器上使用会话状态！ 如果会话状态非常痛苦（例如购物车），请将其存储在中央数据库中，并定期清除旧会话。 如果会话状态不重要（例如用户名/头像URL），那么将其粘贴到cookie中 – 只要确保没有将太多的数据放入cookie即可。
现代版本的Rails，默认情况下，出于上述原因，将会话variables存储在cookie中。 其他的web框架可能有一个“存储在cookie中”和/或“在数据库中存储”选项。
