同域下单点登录的Session同步问题

目录

1.关于什么是单点登录，参考另一篇博客。

2.为什么会有Session同步的问题

3.同域单点登录的Session同步解决方案 

4.总结

---

1.关于什么是单点登录，参考另一篇博客。

2.为什么会有Session同步的问题

在最早期，实现Session是为了集群服务器。以前，程序都是一个进程或者一个软件，没有所谓的分布式和微服务。所以在性能上就会达到瓶颈，所以通常使用集群服务器的方式来解决。

 如图所示，有一个系统使集群。有一客户端在登录时有代理服务器将该请求分发到系统A，使用session来保存登录信息。但如果第二次getUser请求被代理服务器分发到系统B中，则会发生用户信息丢失。客户在系统A中登录，系统B查无此人。因此就产生了Session同步的需求。

3.同域单点登录的Session同步解决方案 

1.IPhash

最原始的方式是iphash方法。通过IP值计算hash值，第一次该客户的的请求由代理服务器nginx发送到了系统A，则以后每次只要是该IP的哈希值，均发给系统A。这样做虽然能解决问题，但是是伪负载均衡，如果系统A挂了，则会造成系统瘫痪，该用户无法正常使用，会产生单点故障。此方法早已被淘汰。

2.session复制

集群服务器的代码逻辑都是相同的。当用户在系统A登录后，其登录信息保存在session域中。集群服务器之间可以进行通讯，进行session同步。说明白点就是将自己的session复制给其他服务器，保证所有正常工作的集群的session域的数据一模一样，让大家都知道这个用户登陆了。

但是这样很不方便，它会占用大量内存，同一份数据在所有集群中都有一份。其同步是有延迟的，而且现在分布式项目根本不使用session，所以现在基本上都使用第三种方式。 

 3.中间存储媒介

第三种方法是在第二种方法的基础上改进的。不用每个集群都保存一份数据，而是在每个服务器处理完之后，将数据保存到一个第三方的存储结构。所有的服务器都会从第三方存储结构中去拿数据。一般使用非关系型数据库Redis作为第三方存储。

 如图所示，不管是分布式服务器还是集群服务器，在用户登录之后会生成一个可以唯一确定客户端的id，依次id为键，以该用户为值将客户端的登录信息存到Redis中，然后会以Token的形式返回key值给客户端。当该客户的在此发起请求时携带Token一起发送，无论哪个服务器处理此次请求，都会从Token中拿到uuid，然后去Redis中查找该用户的信息。如此便可实现单点登录。

4.总结

Session同步技术使得不管是集群服务器，还是分布式服务器，都可以共享用户登录信息。给单点登录的实现贡献了浓墨重彩的一笔。