Zookeeper之Session和Http之Session类比学习

最新推荐文章于 2023-03-16 09:07:44 发布

DavisChen_Infinite

最新推荐文章于 2023-03-16 09:07:44 发布

阅读量863

点赞数

分类专栏：大数据文章标签：大数据

本文链接：https://blog.csdn.net/chen610/article/details/76375343

版权

大数据专栏收录该内容

2 篇文章 0 订阅

订阅专栏

前言

学习，这里将会把Http中的Session和Zookeeper中的Session放在一起来比较学习，以增强理解。首先是会先讲HttpSession然后再讲Zookeeper的Session。

HttpSession

介绍

摘自百度：HttpSession是Java平台对session机制的实现规范，本身仅仅是一个接口。具体的实现是由每个web应用服务器的提供商来实现。也就是说我们经常会用到Tomcat和Jetty还有一些收费的web服务器，他们来根据规范来实现这个接口的功能。下面仅仅从Jetty的HttpSession来说明一下。Http请求是无状态的，因为追求简单的逻辑，就不能满足服务器对一些共享信息和数据的要求。但是Http也提供两种实现该共享数据和信息的方式：

Cookie：所有共享的数据和信息都使用客户端保存，使用cookie在发送请求的时候发送给服务器。同是服务器也可以通过set-cookie方式设置到客户端上。但是我们很容易可以考虑到，每次都需要发送一些cookie，带宽便被占用，同时cookie本身也是由大小限制的。最重要一点是，有些浏览器基于安全的考虑，是不允许使用cookie的。
HttpSession：既然在客户端上保存和发送存在比较多的问题，那么可不可以在服务器端来保存这个共享数据呢。答案是可以的，那么HttpSession就来了。服务端Session便是用来保存共享数据的，本身通过一个很重要的属性sessionId来区分。session保存在服务器，那么就不会出现占用带宽和安全问题。但是本身也是优缺点的，那就是集中式的带来的问题。既然全部集中在服务器上，那么服务器就负担大，因为一般情况下，session是存储在内存中的（分布式系统如果做了session共享，可能会存到redis里面），本身如果服务器进程被停止或者重启的时候，内存里面的session就会被清空（分布式也叫单点问题），当然有些收费的服务器也会做得把session保存到硬盘上，总结这个点，那就是无非占用大量内存或者大量的硬盘。增加的程序的处理逻辑。

主要方法

在jetty里面，这种服务器信息还包括一下信息，SessionId,CreateTime,LastAccessedTime,MaxInactiveInterval,Attributes信息，我们在经常会在Serlvet的SerlvetContext中来获取Session。jetty使用SessionManager来管理Session。Session可以保存在数据库中，这里使用JDBCSessionManager，当然可以可以保存在内存中HashSessionManager。jetty使用AbstractSessionManager的内部类Session来实现HttpSession接口，并且该实现是线程安全的。下面我们来看主要的方法。

getCreationTime():获取创建时间
getId():sessionId，在web应用中唯一标示Session实例，这个有两种ID，分别是：NodeId和ClusterId，而AbstractSessionManager默认是使用ClusterId作为SessionID的。
getLastAccessedTime()：返回最后一次访问时间戳
getServletContext():这个是获取上下文，是我们用得最广泛之一。
setMaxInactiveInterval(int interval)：设置Session的Idle时间，以s为单位。、
getMaxInactiveInterval()
getAttribute(String name): 这里设置属性，如果value传入null，那么则移除该属性。否则覆盖。
getAllAttribute()
setAttribute(String name, Object value)
removeAttribute(String name);
invalidate():Session失效，这个比较厉害，移除所有attribute，并且从SessionManager中移除。
isNew():可以判断是否使用cookie或者session进行交互。

综述

HttpSession是Web应用服务几乎不可以缺少的一个重要的元素。它的生命周期伴随着客户端的一次请求的开始到结束，它绑定着需要重要的关联的共享信息，我们经常会把登录用户的各种共享信息放到其中，让每个操作都能够轻松获取到当前的用户信息。当然在分布式系统中，我们可能需要做的更多，微服务下，我们可能需要做到session共享，保证各个微服务之间能够功效session，而不是再做复杂是重新登录的逻辑。这个时候可能就有更多的方案去实现这个session，比如redis保存session实现共享等。

Zookeeper之Session

我们讲完HttpSession，终于来到我们的主题Zookeeper中的Session，它又是怎么样的呢？它又有什么特性呢？它和我们前面讲到的HttpSession又有什么区别和类似之处呢？让我们来慢慢接口它神秘的面纱，看看是不是眉清目秀，几分相似呢？

介绍

Zookeeper中的session是客户端和服务端之间任何交互操作都需要用到的。同样也报存了许多重要的信息，比如临时节点的生命周期，客户端的请求的顺序执行，还有Watcher通知等。是不是感觉和HttpSession有几分相似呢。下面在多讲几个它的特性。

会话状态

在HttpSession中，我们可能也有两个状态，失效或者不失效，那么Zookeeper的session呢？

CONNECTING：连接中
CONNECTED:已连接
RECONNECTING:重新连接中
RECONNECTED:已经重连
CLOSE:关闭

是不是感觉有些不一样了，session复杂了很多，但是无不围绕着Zookeeper本身客户端和服务端这种类似CS的交互方式。

会话创建

也类似于我们的浏览器向web服务器发送一个请求，建立http连接后创建的session类似，Zookeeper客户端请求连接到Zookeeper服务器后，本身也维护着一个session，这里面也包括了上面我们看到了重要的属性：

sessionId:会话ID
TimeOut:会话超时时间
TickTime:下次会话超时时间点
isClosing:是否已经被关闭

每次SessionId都要被拎出来聊聊，其中发挥的重要作用真是不言而喻啊。在Http的session中，sessionId也必须是全局唯一的，但是那只是针对单个web服务器提供的SessionManager管理的session而言，那么对于Zookeeper又是如何呢？Zookeeper作为分布式系统中重要的作为协调分布式服务的重要中间件，它到底又是怎么实现在分布式系统中完成Zookeeper集群的时候session共享的呢?

    public static long initializeNextSession(long id ){
        long nextSid = 0;
        nextSid = (System.currentTimeMillis() << 24) >> 8;
        nextSid = nextSid | (id << 56);
        return nextSid;
    }

书上说这段生产代码有bug。后续版本进行了更正，见下面

    public static long initializeNextSession(long id ){
        long nextSid = 0;
        nextSid = (System.currentTimeMillis() << 24) >>> 8;
        nextSid = nextSid | (id << 56);
        return nextSid;
    }

Http的Session有SessionManager管理，Zookeeper的Session也是有管理的，这个管理类就是SessionTracker，它也是一个会话管理器，负责Zookeeper服务端的session创建、管理、清理等工作。这里摘自书上《从PAXOS到Zookeeper分布式一致原理》，SessionTracker使用分桶策略，即将类似的session放到一个区块中进行管理，以便于Zookeeper对会话进行不同区块的隔离处理以及同一个区块的管理。

会话激活

Zookeeper的客户端和服务端之间会根据我们配置文件中设置的ticket时间来持续的想服务器发送PING请求，保证自己和服务器之间的session不会超时。俗称“心跳检测”。服务根据客户端的不断的PING请求，重新激活对应客户端的session，这个叫TouchSession。看下面流程图：
这里写图片描述

会话超时检查

SessionTracker使用一个单独的线程专门进行会话超时检查。这个比较简单不做介绍。

会话清理

清理Session我们可以看下面的流程图来进行理解。HttpSession中会话的清理没有Zookeeper的Session清理那么复杂，但是也是脱离不了这样的设计框架。在Zookeeper中更加体现了客户端和服务器之间的连接关系、心跳等。下面看流程图进行理解。
这里写图片描述

总结

Http的Session和Zookeeper的Session有很多共通之处，但是又各不相同。一个简单些一个更为复杂些。Zookeeper的Session是的客户端和服务端的方式，以及他构建SessionID的方式都是为它能更好的在Zookeeper集群中更好的服务。Zookeeper的Session配合它独一无二的ZNode的特性，将是它在分布式集群中占有更大作用的基本需要的功能。后续将会更加深入了解Zookeeper集群将是怎么使用这些特性进行主备切换，master选举等。