单点登录实现和多服务器下解决共享session共享的方案

单服务器下,状态的记录

➢ 如果网站请求流量较大，那么单台 tomcat 设备是无法承接这些流量的，这个时候就需要开始对服务器做集群。在多服务器下我们通常要在客户端和服务器之间用一定的条件(比如按业务划分了)做一个负载均衡服务器LB(load balance),将不同的请求划到不同的服务器上进行处理,这就可能出现我们在一台服务器上记录了sessionid而其他服务器上没有的情况,若服务器将请求转发到这个没有sessionid的服务器,那么请求就又变成无连接的了

关于负载均衡

负载均衡的主要目的是：把用户的请求分发到多台后端的设备上，用以均衡服务器的负载。我们可以把负载均衡器划分为两大类：硬件负载均衡器和软件负载均衡器。

负载均衡服务器

• 硬件负载均衡服务器(F5/redware) F5四层负载,reaware7层负载 内嵌一些集成好的负载均衡算法等,可以直接使用但是贵最便宜的要几十万

所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量 四层的负载均衡，就是通过发布三层的 IP 地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。 七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个 Web 服务器的负载均衡，除了根据 VIP(virtual ip)加 80 端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的 Web 服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。

• 软件负载均衡服务器( LVS(Linux Virtual Server) , HAProxy , Nginx) 不同的负载均衡技术有不同的特点， 比如 LVS 是基于 4 层的负载负载技术，抗负载能力比较强 HAProxy 和 Nginx 是基于 7 层的负载均衡技术，需要根据请求的 url 进行分流

负载均衡算法

引入负载均衡器以后，就势必需要一个负载均衡算法对请求进行转发，那么，常见的负载均衡算法有以下几种

• 1·轮询算法或者轮询加权算法 思想很简单，就是提供同质服务的节点逐个对外提供服务，这样能做到绝对的均衡 加权轮训算法就是在轮训算法的基础上，考虑到机器的差异性，分配给机器不同的权重，能者多劳。注意，这个权重的分配依赖于请求的类型，比如计算密集型，那就考虑CPU、内存；如果是IO密集型，那就考虑磁盘性能。
• 2随机算法 这个就更好理解了，随机选择一个节点服务，按照概率，只要请求数量足够多，那么也能达到绝对均衡的效果。而且实现简单很多
• 3.hash算法 根据客户端的IP，或者请求的“Key”，计算出一个hash值，然后对节点数目取模。好处就是，同一个请求会计算一样的hash值这样就能够分配到同样的服务节点进行处理，这对于“有状态”的服务很有必要：
• 4最小连接数 哪台服务器连接数比较少就把请求落到哪个服务器上

Session 共享问题的解决方法

Session 共享问题，其实已经有非常多的解决方案，那么接 下来我们一一分析

session sticky

session sticky(粘性) , 保证同一个会话的请求都在同一个web 服务器上处理，这样的话，就完全不需要考虑到会话的问题了。比如前面说的负载均衡算法中，哈希算法就是一个典型的实现手段。 这种实现方式会有些问题：

1. 如果一台 web 服务器宕机或者重启，那么这台机器上保存的会话数据都会丢失，会造成用户暂时无法访问的问题，或者用户之前的授权操作需要再执行一次
2. 通过这种方式实现的 session 保持，没有办法进行 4 层网络转发，只能在 7 层网络上进行解析并转发session replicationsession 复制，通过相关技术实现 session 复制，使得集群中的各个服务器相互保存各自节点存储的 session 数据。tomcat 本身就可以实现 session 复制的功能，基于 IP 组播方式。大家课后可以去了解下如何配置 这种实现方式的问题：
3. 同步 session 数据会造成网络开销，随着集群规模越大，同步 session 带来的带宽影响也越大
4. 每个节点需要保存集群中所有节点的 session 数据，就需要比较大的内存来存储。

session 统一存储

集群中的各个节点的 session 数据，统一存储到一个存储设备中。那么每个节点去拿 session 的时候，就不是从自己的内存中去获得，而是从相应的第三方存储中去拿。对于这个方案来说，无论是哪个节点新增或者修改了 session 数据，最终都会发生在这个集中存储的地方。

这个存储设备可以是 redis、也可以是 mysql。

这种实现方式的问题：

1. 读写 session 数据需要进行网络操作，存在不稳定性和延迟性
2. 如果存储 session 的服务器出现故障，将大规模的影响到应用

Cookie Based(JWT Jsession web token)

Cookie Based 方法，简单来说，就是不依赖容器本身的Session 机制。 而是服务端基于一定的算法，生成一个 token 给到客户端，客户端每次请求，都会携带这个 token。当服务端收到 token 以后，先验证 token 是否有效，再解密这个 token 获取关键数据进行处理