方案：
1、基于request的负载均衡
该种方式下，负载均衡器 (load balancer)会根据各个node的状况，把每个 http request进行分发。使用这样的均衡策略，就必须在多个node之间复制用户的session，实时保持整个cluster的用户状态同步，这种操作被称为session复制(session replication)。Jboss的实现原理是使用拦截器(interceptor)，根据用户的同步策略拦截request，做同步处理后再交给server产生响应。
优点是客户不会被绑定都具体的node，只要还有一个node存活，用户状态都不会丢失，cluster都能够继续工作。
缺点是node之间通信频繁，响应速度有影响，多并发、高频操作的情况下性能下降比较厉害。
2、 基于用户的负载均衡
该种方式下，当用户发出第一个request后，负载均衡器动态的把该用户分配到某个节点，并记录该节点的jvm路由，以后该用户的所有request都会被绑定这个jvm路由，用户只会与该server发生交互，这种策略被称为粘性session(session sticky)。
优点是响应速度快，多个节点之间无须通信。
缺点也很明显，某个node死掉以后，它负责的所有用户都会丢失session。
个人理解：所谓黏性session，也就是负载均衡，从客户端的角度出发，未实现真正意义上的集群，没有实现session在tomcat之间的复制。因为，cookie中记录了是来自哪个tomcat，比如来自tomcat1，如果tomcat1 down掉，那么，这个tomcat关联的所有用户都会dow掉。
黏性session（session sticky）：就是常说的负载均衡，还没有实现真正意义上的集群，如果某个节点down掉，这个节点关联的所有客户端都将down掉
session复制（session replication）：就是session在各个tomcat间复制，实现了真正意义上的集群，如果某个节点down掉，不会影响客户端
