单点登录实现

分布式Session即Session共享

如果我们是同一个网站，在多台服务器上部署，并且访问同一个域名，这种类似于分布式session，目前比较简单的解决方案用nginx做代理就可以实现。

在单服务器web应用中，登录用户信息只需存在该服务的session中，这是我们几年前最长见的办法。而在当今分布式系统的流行中，微服务已成为主流，用户登录由某一个单点服务完成并存储session后，在高并发量的请求（需要验证登录信息）到达服务端的时候通过负载均衡的方式分发到集群中的某个服务器，这样就有可能导致同一个用户的多次请求被分发到集群的不同服务器上，就会出现取不到session数据的情况，于是session的共享就成了一个问题。目前实现session共享的解决方案：

1）Session复制与共享 多个server之间相互同步session，这样每个server上都包含全部Service的session。

优点：tomcat等多数主流web服务器都支持此功能。

不足：session同步需要数据传输，占内网带宽，有时延。所有服务器都包含所有session数据，特别是当session中保存了较大的对象，而且对象变化较快时，性能下降显著，这种特性使得web应用的水平扩展受到了限制。

2）客户端存储法 服务端存储所有用户的session，内存占用较大，也可以将session存储到浏览器cookie中，每个端只要存储一个用户的数据了。

优点：服务端不需要存储

缺点：每次http请求都携带session，占外网带宽数据存储在端上，并在网络传输，存在泄漏、篡改、窃取等安全隐患。session存储的数据大小受cookie限制。

3）反向代理hash一致性 为了保证高可用，有多台冗余，反向代理层能不能做一些事情，让同一个用户的请求保证落在一台web服务器上呢？具体方案：反向代理使用IP或http协议中的某些业务参数来做hash，以保证同一个浏览器用户的请求落在同一个web服务器上。

优点：只需要改nginx配置，不用改应用代码，负载均衡，只要hash属性是均匀的，多台web服务器的负载是均衡的。可以支持web服务器水平扩展（session同步法是不行的，受内存限制）

缺点：如果web服务器重启，一部分session会丢失，产生业务影响，例如部分用户重新登录。如果web服务器水平扩展，rehash后session重新分布，也会有一部分用户路由不到正确的session。

4）服务端集中存储 将session存储在后端的存储层，如：数据库或者缓存。客户端每发次一次请求，都会先从存储中获取，再处理具体的业务逻辑。

优点：无安全隐患，可以水平扩，服务器重启或者扩容都不会造成session丢失。

不足：增加了一次网络调用，要修改应用代码。

总结：一般对单点登录和session共享的处理，大都选择在服务端集中存储来实现。对于db存储还是cache，肯定cache是首选。因为session读取的频率会很高，使用数据库压力会比较大。如果有session高可用需求，cache可以做高可用，但大部分情况下session可以丢失，一般也不需要考虑高可用。目前主流的现实方案是用redis实现session的存储。

单点登录

如果是不同网站，我们要做到登陆A系统，同时从A系统跳转到B系统并且B系统不用登陆，B系统登录后也可以跳转到A系统并且A系统也不需要登陆，系统可以扩展到N个，这种是单点登录，并且涉及到跨域的处理，这种解决方案目前看来有Oauth2.0，JWT 等单点登录（SSO）框架，并且最好每个系统都集成单点登录才是比较好的，或者做一个认证中心，实现登陆认证中心后可以跳转到A,B系统，这时候A,B系统即可以做单点登录也可以不再做单点登陆