本文主要讲述集群环境下解决Session共享的问题，从而实现集群环境下的单点登录。Session共享问题已经有很多解决方案，这里主要讲述常用四种方法。
Session Sticky
Session Sticky(粘性) 保证同一个会话的请求都在同一个Web服务器上处理，这样就完全不需要考虑到会话问题了。比如负载均衡算法中哈希算法就是一个典型的Session Sticky实现手段。
这种实现方式存在问题：
1）如果一台Web服务器宕机或者重启，那么这台机器上保存的会话数据都会丢失，会造成用户暂时无法访问的问题，之前的授权操作需要再执行一次；
2）通过这种方式实现的Session保持，无法进行4层网络转发，只能在7层网络上进行解析并转发。
Session Replication
Session Replication（复制）通过相关技术实现Session复制，使集群中的各个服务器保存所有节点的session数据。tomcat本身就可以实现session复制的功能，基于IP组播放方式。
这种实现方式的问题：
1）同步Session数据会造成网络开销，随着集群规模越大，同步Session带来的带宽影响也越大；
2）每个节点需要保存集群中所有节点的Session数据，就需要比较大的内存来存储。
Session统一存储
集群中的各个节点的Session数据，统一存储到一个存储设备中。客户端访问需要Session的时候，就不是从某个节点的内存中去获得，而是从相应的第三方存储中去获取。对于这个方案来说，无论是哪个节点新增或者修改了Session数据，最终都会发生在这个集中存储的地方。采用的Session存储有redis、mysql。
这种实现方式的问题：
1）读写Session数据需要进行网络操作，存在不稳定性和延迟性；
2）如果存储Session的服务器出现故障，将大规模的影响到应用。
Cookie Based
Cookie Based方法简单来说，就是不依赖容器本身的Session机制。而是服务端基于一定的算法，生成一个token给到客户端，客户端每次请求都会携带这个token。当服务端收到token 以后，先验证token是否有效，然后对客户端访问进行授权。
比较典型的方式是JWT（JSON Web Tokens），它是一种简洁的并且在两个计算机之间安全传递信息的表述性声明规范。JWT的声明一般被用来在客户端和服务端之间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。