当您的网站仅由一个web服务器提供服务时，对于每个客户端-服务器对，都会创建一个会话对象，并保留在web服务器的内存中。所有来自客户端的请求都发送到这个web服务器并更新这个会话对象。如果在交互期间需要将某些数据存储在会话对象中，则将其存储在此会话对象中，并在会话存在期间一直保存在那里。

然而，如果你的网站是由位于负载均衡器后面的多个web服务器提供服务的，负载均衡器决定每个请求应该去哪个实际的(物理的)web服务器。例如，如果负载均衡器后面有3个web服务器A、B和C，则可能由服务器A提供www.mywebsite.com服务，由服务器B提供www.mywebsite.com服务，由服务器C提供www.mywebsite.com/服务。

Now, if the requests are being served from (physically) 3 different servers, each server has created a session object for you and because these session objects sit on three independent boxes, there's no direct way of one knowing what is there in the session object of the other. In order to synchronize between these server sessions, you may have to write/read the session data into a layer which is common to all - like a DB. Now writing and reading data to/from a db for this use-case may not be a good idea. Now, here comes the role of sticky-session.

如果负载均衡器被指示使用粘滞会话，那么您的所有交互都将发生在同一台物理服务器上，即使存在其他服务器。因此，在与该网站的整个交互过程中，会话对象将是相同的。

总之，在粘性会话的情况下，所有的请求都将被定向到同一个物理web服务器，而在非粘性负载均衡器的情况下，可以选择任何web服务器来服务您的请求。

举个例子，你可以在这里读到Amazon的弹性负载均衡器和粘性会话:http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

我在这里做了详细的回答: https://stackoverflow.com/a/11045462/592477

或者你可以在这里读==>

当您使用负载平衡时，这意味着您有几个tomcat实例，您需要划分负载。

If you're using session replication without sticky session : Imagine you have only one user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send some of these requests to the first tomcat instance, and send some other of these requests to the secondth instance, and other to the third. If you're using sticky session without replication : Imagine you have only one user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send the first user request to one of the three tomcat instances, and all the other requests that are sent by this user during his session will be sent to the same tomcat instance. During these requests, if you shutdown or restart this tomcat instance (tomcat instance which is used) the loadbalancer sends the remaining requests to one other tomcat instance that is still running, BUT as you don't use session replication, the instance tomcat which receives the remaining requests doesn't have a copy of the user session then for this tomcat the user begin a session : the user loose his session and is disconnected from the web app although the web app is still running. If you're using sticky session WITH session replication : Imagine you have only one user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send the first user request to one of the three tomcat instances, and all the other requests that are sent by this user during his session will be sent to the same tomcat instance. During these requests, if you shutdown or restart this tomcat instance (tomcat instance which is used) the loadbalancer sends the remaining requests to one other tomcat instance that is still running, as you use session replication, the instance tomcat which receives the remaining requests has a copy of the user session then the user keeps on his session : the user continue to browse your web app without being disconnected, the shutdown of the tomcat instance doesn't impact the user navigation.

假设用户发送了一个请求来获取它的配置文件，在我们的web应用程序实例的内存中不会有任何东西。我们在发送响应之前从DB nit中获得用户配置文件，我们将数据保存在内存中，比如说Instance3。但是来自同一用户的下一个请求可以发送到任何实例。

When the request first comes to Instance3, that time it will create a session that will have a session id. when the response is sent to the client, the client is supplied with a cookie. so next time this client makes a request, this cookie will be attached to the request, the load balancer will look at the cookie, and the load balancer will know that that request has to be forwarded to Instance3. This is sticky session solution. Its downside is what if Instance3 goes down? the load balancer will route the request to other instances but they do not have a cache. All the users stored in Instance3 will have high latency. This will impact the reliability of your system.

如果将会话存储在所有实例中，现在就会出现内存问题。假设一个实例可以存储100个用户会话，而您有3个实例，那么您将能够存储300个会话。但是如果每个实例存储每个会话，那么在所有3个实例中只能存储100个会话。这将影响应用程序的可伸缩性。

粘性会话和非粘性会话是有状态复制的组成部分。如果你想要更高的可伸缩性，你不需要在你的web应用实例上缓存任何东西，你的web实例会在每个请求时都访问数据库，但这会导致高延迟。

更好的方法是无状态复制，即不在应用程序实例上存储任何东西，而是使用服务器端缓存(memcached/redis)。