session没落,现在的会话都是如何实现的?

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接: https://blog.csdn.net/hebtu666/article/details/102711678

什么是会话?

  会话可简单理解为:用户开一个浏览器,点击多个超链接,访问服务器多个web资源,然后关闭浏览器,整个过程称之为一个会话。

•会话过程中要解决的一些问题?

–每个用户不可避免各自会产生一些数据,程序要想办法为每个用户保存这些数据。

–例如:用户点击超链接通过一个servlet购买了一个商品,程序应该想办法保存用户购买的商品,以便于用户点结帐servlet时,结帐servlet可以得到用户购买的商品为用户结帐。

•Cookie

–Cookie是客户端技术,程序把每个用户的数据以cookie的形式写给用户各自的浏览器。当用户使用浏览器再去访问服务器中的web资源时,就会带着各自的数据去。这样,web资源处理的就是用户各自的数据了。

•HttpSession

–Session是服务器端技术,利用这个技术,服务器在运行时可以为每一个用户的浏览器创建一个其独享的HttpSession对象,由于session为用户浏览器独享,所以用户在访问服务器的web资源时,可以把各自的数据放在各自的session中,当用户再去访问服务器中的其它web资源时,其它web资源再从用户各自的session中取出数据为用户服务。

总结:cookie存在客户端,session存在服务器端

 通常结合使用。

我们先用sprintboot演示一下cookie和session操作

    @RequestMapping(path = "/cookie/set",method = RequestMethod.GET)
    @ResponseBody
    public String setCookie(HttpServletResponse httpServletResponse){
        Cookie cookie=new Cookie("code", CommunityUtil.generateUUID());
        cookie.setPath("/community/alpha");
        cookie.setMaxAge(60*10);
        httpServletResponse.addCookie(cookie);
        return "set cookie";
    }


    @RequestMapping(path = "/cookie/get",method = RequestMethod.GET)
    @ResponseBody
    public String getCookie(@CookieValue("code") String code){
        System.out.println(code);
        return "get cookie";
    }


    @RequestMapping(path = "/session/set", method = RequestMethod.GET)
    @ResponseBody
    public String setSession(HttpSession session){
        session.setAttribute("id",1);
        session.setAttribute("name","Test");
        return "set session";
    }


    @RequestMapping(path = "/session/get", method = RequestMethod.GET)
    @ResponseBody
    public String getSession(HttpSession session) {
        System.out.println(session.getAttribute("id"));
        System.out.println(session.getAttribute("name"));
        return "get session";
    }

其实session的没落是和分布式有关的,随着服务器要处理的请求越来越多,我们不得不分布式部署,减小服务器压力。

为了负载均衡,我们一般采用nginx来分发请求给各个服务器处理

但是这样session是无法共享的。

(粘性session)

你可以设置nginx的分配策略,下次同一个还让同一个服务器来处理

但是很显然,这就和分布式和nginx初衷违背了:负载很难保证均衡。

(同步session)

一台服务器的session给所有服务器复制一份

第一,性能不好。第二,产生了一定的耦合

(专门session)

专门一台服务器来解决,存session,其它服务器来这个服务器取session再用。

但是也有问题:你这个服务器挂了怎么办?别的服务器都是依赖这个服务器工作的。我们分布式部署本来就是为了解决性能的瓶颈啊。

很容易想到,我们把那个处理session的服务器搞个集群:

更不行,想想就知道,本来就是为了解决分布式部署的问题,你把单独解决session的服务器又搞集群,和之前有什么区别呢?还不如一个服务器存一份简单呢。

(存数据库)

可以,但是传统的关系数据库是存到硬盘里,速度太慢。

(nosql)

最终,我们的主流办法使用nosql数据库,比如redis,来解决这个问题的。

猜你喜欢

转载自blog.csdn.net/hebtu666/article/details/102711678