分布式系统登录原理

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)  设置存活时间,单位为秒
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页