粘滞和不粘的会议
我想知道粘滞会话和非粘滞会话之间的区别。 从互联网上阅读后，我明白了什么：
粘滞 ：只有单个会话对象将在那里。
非粘性会话 ：每个服务器节点的会话对象
当您的网站只有1 web server ，每对会话对象被创build并保留在Web服务器的内存中。 来自客户端的所有请求都转到此Web服务器并更新此会话对象。 如果某些数据需要在交互期间存储在会话对象中，则只要会话存在，它就存储在此会话对象中，并保留在该会话对象中。
但是，如果您的网站由位于load balancer后面的multiple web servers ，那么负载平衡器将决定每个请求应使用哪个实际（物理）Web服务器。 例如，如果在负载平衡器后面有3个Web服务器A，B和C，则有可能从服务器A提供www.mywebsite.com/index.jsp，服务器提供www.mywebsite.com/login.jsp B和www.mywebsite.com/accoutdetails.php从服务器C提供。
现在，如果请求是通过（物理）3个不同的服务器提供的，则每个服务器都为您创build了一个会话对象，并且因为这些会话对象位于3个独立的盒子上，所以没有直接的方式知道会话对象中有什么另一个。 为了在这些服务器会话之间进行同步，您可能必须将会话数据写入/读取到所有通用层（如DB）。 现在为这个用例写入和从数据库读取数据可能不是一个好主意。 现在， 粘滞会话的作用就来了。 如果指示load balancer使用粘性会话，即使存在其他服务器，您的所有交互也将发生the same physical server 。 因此，您的会话对象在您与本网站的整个交互过程中将保持不变。
总而言之，在Sticky Sessions的情况下，所有请求都将被定向到相同的物理Web服务器，而在非粘性负载均衡器的情况下，可以select任何Web服务器来为您的请求提供服务。
作为一个例子，你可以在这里阅读亚马逊的Elastic Load Balancer和粘性会话： http : //aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html
我已经在这里提供了一些更多细节的答案： https : //stackoverflow.com/a/11045462/592477
或者你可以阅读它==>
当你使用负载平衡，这意味着你有几个tomcat的实例，你需要分开负载。
- 如果您使用的会话复制没有粘性会话：想象一下，您只有一个用户使用您的Web应用程序，并且您有3个Tomcat实例。 这个用户向你的应用发送了几个请求，然后负载均衡器将这些请求中的一部分发送到第一个tomcat实例，并将这些请求中的一些发送到第二个实例，其他的发送到第三个。
- 如果您在不使用复制的情况下使用粘性会话：假设您只有一个用户使用您的Web应用程序，并且您有3个Tomcat实例。 此用户向您的应用发送多个请求，然后负载均衡器将第一个用户请求发送到三个tomcat实例之一，并且此用户在其会话期间发送的所有其他请求将被发送到同一个tomcat实例。 在这些请求期间，如果closures或重新启动这个tomcat实例（使用的tomcat实例），loadbalancer将剩余的请求发送给另一个仍在运行的tomcat实例，但是因为您不使用会话复制，所以接收的实例tomcat其余的请求没有用户会话的副本，那么对于这个tomcat用户开始一个会话：虽然web应用程序仍在运行，但是用户松开了他的会话并与web应用程序断开连接。
- 如果您使用粘性会话与会话复制：想象一下，您只有一个用户使用您的Web应用程序，并且您有3个Tomcat实例。 此用户向您的应用发送多个请求，然后负载均衡器将第一个用户请求发送到三个tomcat实例之一，并且此用户在其会话期间发送的所有其他请求将被发送到同一个tomcat实例。 在这些请求期间，如果您closures或重新启动这个tomcat实例（使用的tomcat实例），那么在您使用会话复制时，负载均衡器会将剩余的请求发送给另一个仍在运行的tomcat实例，接收剩余请求的实例tomcat具有用户会话的副本，然后用户继续他的会话：用户继续浏览您的Web应用程序而不断开，closures的tomcat实例不会影响用户的导航。
