分布式系统登录原理

1.传统系统登录

        user ----> server1    

        即用户user在服务server1上输入登录名、密码等信息；server1完成用户信息校验，并将对应信息写入server1的session中。

        问题：分布式系统，微服务架构中，在server1中完成登录，但是访问server2时仍需登录。

 

2.分布式架构模型下的登录问题剖析

        常见的如图，将一个项目，分为多个server，部署在不同的服务器。如wucenter，部署在3个服务器上，即server1  、server2 、server3等。通常会使用Nginx进行负载均衡，默认为便利的方式，例本次请求分发至server1，下次分发至server2 ，下下次分发至server3。当用户在server1完成登录操作后，下次请求getPhone操作，此时请求被分发至server2，在传统登录模型中，由于server2中不含有在server1登录后保存的session信息，此时仍需登录。

 

3.处理方案

       a. iphash的处理方案：

       即在Nginx中，将请求来访的Ip和对应的server进行绑定，从而保证同一ip地址的请求均是在同一个服务器下，避免了分发不同请求时的session问题。

       问题：server1宕机时导致大量的请求失败，会存在大量的请求被分发至同一服务器导致负载均衡失效。

       b.session同步的处理方案

        即当用户在server1完成登录后，会通过服务器的http请求将session下发至其他的所有的server中。

        问题：同一session在各个服务器上保存导致内存占用问题，网络通讯延时导致的server2中的session获取不及时问题

        c.redis方式

        即通过key-value的方式，在server1完成登录后，将用户信息以value的形式，保存在redis中。同时将key发送至客户端的cookie中。客户端下次发送请求时，Negix分发到的server，通过cookie中获取key，进而从redis中获取对应的用户信息的操作。

        优点：安全

        核心问题：key的生成以及发送问题。

以淘宝-天猫为例剖析redis实现的分布式登录问题

        1.用户在淘宝发起登录请求，输入账户名密码；

        2.淘宝验证通过后，将对应的用户信息封装为value，并产生一个key，将key-value存储到一个store系统中；

        3.淘宝将对应的key通过cookie发送到客户端；

        4.用户下次从天猫获取数据时，http请求会携带对应的cookie信息，发送请求到天猫；

        5.天猫解析对应的cookie，获取到对应的key，从store系统获取对应的用户信息，进而执行其他操作；获取失败则返回登录页面，使用户重新登录。

cookie的相关操作

       1.如果在Cookie中设置了"HttpOnly"属性，那么通过JavaScript脚本将无法读取到Cookie信息，这样能有效的防止XSS攻击，让网站应用更加安全。

        2.cookie的相关方法

                setName(String name)   修改Session ID的名称，默认为"JSESSIONID"
                setDomain(String domain) 设置当前Cookie所处于的域
                setPath(String path) 设置当前Cookie所处于的相对路径
                setHttpOnly(boolean httpOnly) 设置是否支持HttpOnly属性
                setSecure(boolean secure) 若使用HTTPS安全连接,则需要设置其属性为true
                setMaxAge(int maxAge)  设置存活时间，单位为秒