Tomcat内核详解（十九）：多样化的会话管理器

1.Web容器的会话机制

【客户端是如何把jsessionid传递到服务端的呢？】

一般会有三种方式：

①cookie方式，即通过浏览器读取小文本cookie，读取jsessionid值后附加到http协议的cookie头部，http协议报文传输到服务端后解析cookie头部便可以获取，但如果你把浏览器的cookie给禁止了则这种方式会失效。

②重写url方式，即把jsessionid附加到请求的url中，例如http://www.tomcat.com/index.jsp?jsessionid=326257DA6DB76F8D2E38F2C4540D1DEA。

③表单隐藏方式，这种方式其实类似重写url方式，我们把jsessionid及其值存放在html表单中，提交时就会一起被提交，服务端只要根据post或get方法分别解析便可获取到。

Web容器的会话机制补充了http协议的无状态性，使web在应用功能方面更加强大，满足了更多更复杂的需求。不管是web应用层开发人员还是中间件开发人员深入理解session机制在软件设计时都会有很大的帮助。

 

2.标准会话对象——StandardSession

Tomcat使用了一个StandardSession对象用来表示标准的会话结构，用来封装需要存储的状态信息。标准会话对象StandardSession实现了Session、Serializable、HttpSession等几个接口，为什么需要实现这几个接口呢？Session接口定义了tomcat内部用来操作会话的一些方法；Serializable则是序列化接口，实现它是为了方便传输及持久化；HTTPSession是Servlet规范中为会话操作而定义的一些方法，作为一个标准web容器实现它是必然的。另外还会存在一个StandardSessionFacade的外观类，外观设计模式相信大家都很熟悉了，前面的Request及Response也使用了同样的模式，都是出于安全考虑引入一个外观类，它可以把一些tomcat内部使用的方法屏蔽了，只暴露web应用层允许调用的一些方法。

 

一个最简单的标准会话应该包括id和Map结构的attribute，id用于表示会话编号，它必须是全局唯一的，attribute用于存储会话相关信息，以kv结构存储。另外还应该包括会话创建时间、事件监听器、提供web层面访问的外观类等等。

 

3.增量会话对象——DeltaSession

在集群环境中为了使集群中各个节点的会话状态都同步，同步操作是集群重点解决的问题，一般来说有两种同步策略:

其一是每次同步都把整个会话对象传给集群中其他节点，其他节点更新整个会话对象；

其二是对会话中增量修改的属性进行同步。这两种同步方案各有优缺点，整个会话对象同步策略实现过程比较简单方便，但会造成大量无效信息的传输。增量同步方式则不会传递无效的信息，但在实现上会比较复杂因为涉及到对会话属性操作过程的管理。

这节讨论的正是增量同步方式中涉及的会话对象DeltaSession，这个对象其实是对标准会话对象的扩展使之具备在整个请求过程记录会话所有的增量更改。DeltaSession的类图如下，除了继承StandardSession类外还实现了Externalizable、ClusterSession、ReplicatedMapEntry三个接口，Externalizable接口主要提供对外部的对象读写操作，ClusterSession接口主要提供判断集群会话是否为原始的会话操作，只有原始会话才有资格使会话过期，ReplicatedMapEntry接口提供差异复制的操作。对于DeltaSession其实就是除了继承StandardSession特性外还要额外实现这三个接口。

当客户端发起一个请求时，服务端对请求的处理可能涉及会话相关的操作，例如获取客户端某些属性再根据属性值进行逻辑处理，而且在整个请求过程中可能涉及多次的会话操作，为了将这些改变能同步到集群的其他节点上，必须要有一个机制来实现，实际上同步的颗粒度大小是很重要，颗粒度太大会导致同步不及时，而颗粒度太小则可能导致传输及性能问题，考虑到性能及可行性，tomcat同步的颗粒度是以一个完整的请求为单位的，即从客户端发起请求到服务器完成逻辑处理返回结果之前这段时间为同步颗粒度。这个过程中对某会话的所有操作（对同一个属性的操作只记录最新的操作）都会被记录下来，如下图，绿色箭头表示一个完整的请求过程，期间包括了四个修改属性操作，分别修改了属性a、b、c、d，这四个操作会被抽象成四个动作放进一个列表中，集群其他节点获取列表后根据这些动作就可以对自己本地对应的会话进行同步。

集群成员接收到某节点发送过来的同步消息后，将会逐一执行动作集里面的每个动作，下图大箭头表示同步的整个过程，最下面的为动作集列表，一共有4个动作，按顺序首先取出第一个update1动作，动作对象里面包含了指定修改哪个会话的会话id，根据此id去修改会话集对应的会话的属性。接着把剩下的其余3个动作执行完毕，于是完成了会话同步。 

在tomcat中会话增量的具体由DeltaSession类实现，DeltaSession继承了StandardSession标准会话的所有特性且增加了会话增量记录的功能，增量记录功能即通过动作集实现，动作集被封装在DeltaRequest类，所以DeltaSession主要通过DeltaRequest实现动作集的管理，动作集由一个LinkedList结构保存，AttributeInfo描述了动作的一些消息，所以一个动作就被抽象成了一个AttributeInfo对象，它主要包含四个属性 name(String)、value(Object)、action(int)、type(int)，name表示会话的属性名，即哪个属性被改；value表示会话属性名对应的值；action表示动作类型，可能是设置属性也可能是删除属性；type表示会话哪种类别的属性将被修改。

整个增量会话的实现机制就是上面所说的，会话的增量拷贝比起全量拷贝有很多好处，即使实现相对比较复杂。

4.增量会话管理器——StandardManager

用于保存状态的会话对象已经有了，现在就需要一个管理器来管理所有会话，例如会话id生成、根据会话id找出对应的会话、对于过期的会话进行销毁等等操作。

用一句话描述标准会话管理器：提供一个专门管理某个web应用所有会话的容器，并且会在web应用启动停止时刻进行会话重加载和持久化。

会话管理主要提供的功能包括会话ID生成器、后台处理（处理过期会话）、持久化模块及会话集的维护。

首先看会话ID生成器，它负责为每个会话生成分配一个唯一标识，例如最终会生成类似“326257DA6DB76F8D2E38F2C4540D1DEA”字符串的会话标识，具体的默认生成算法主要依靠jdk提供的SHA1PRNG算法，如果在集群环境中，为了方便识别会话归属，它最终生成的会话标识类似于“326257DA6DB76F8D2E38F2C4540D1DEA.tomcat1”，后面会加上tomcat集群标识jvmRoute变量值，这里假设其中一个集群标识配置为“tomcat1”。如果你想置换随机数生成算法，可以通过配置server.xml的manager节点secureRandomAlgorithm及secureRandomClass属性达到修改算法的效果。

 

其次看下如何对过期会话进行处理。负责对会话是否过期的逻辑判断主要在backgroundProcess模块，在tomcat容器中会有一条线程专门用于执行后台处理，当然也包括标准会话管理器的backgroundProcess，不断循环判断所有的会话中是否有过期的，一旦过期则从会话集中删除此会话。

 

 

最后是关于持久化模块和会话集的维护，由于标准会话定位于提供一个简单便捷的管理器，所以持久化和重加载操作并不会太灵活且扩展性弱，tomcat会在每个StandardContext（web应用）停止时调用管理器将属于此web应用的所有会话持久化到磁盘，文件名为SESSIONS.ser，而目录路径则由server.xml的Manager节点pathname指定或Javax.servlet.context.tempdir变量指定，默认存放路径为%CATALINA_HOME%/work/Catalina/localhost/web’name/SESSIONS.ser。当web应用启动时又会加载这些被持久化的会话，加载完成后SESSIONS.ser文件将会被删除，所以每次启动成功后就不会看到此文件的存在。另外会话集的维护是指提供创建新会话对象、删除指定会话对象及更新会话对象的功能。

标准会话管理器是我们常用的会话管理器，也是tomcat默认的一个会话管理器，对它进行深入了解有助于对tomcat会话功能的把握，同时对后面其他会话管理器的理解也更容易。

5.持久化会话管理器——PersistentManager

前面提到的标准会话管理器已经提供了基础的会话管理功能，但在持久化方面做得还是不够，或者说在某些情景下无法满足要求，例如把会话以文件或数据库形式存储到存储介质中，这些都是标准会话管理器无法做到的，于是另外一种会话管理器被设计出来——持久化会话管理器。

在分析持久化会话管理器之前不妨先了解另外一个抽象概念会话存储设备Store，引入这个概念是为了更清晰方便地实现各种会话存储方式。作为存储设备最重要的操作无非就是读写操作，读即是将会话从存储设备加载到内存中，而写则将会话写入存储设备中，所以定义了两个重要的方法load和save与之相对应。FileStore和JDBCStore只要扩展Store接口各自实现load和save方法即可分别实现以文件或数据库形式存储会话。UML类图如下所示：

5.1 FileStore

1) FileStore

文件存储设备提供的是以文件形式保存会话，在写入时会针对每个会话生成一个文件用于保存此会话的相关信息，每个会话文件名被定义为sessionId+”.session”的格式，例如“326257DA6DB76F8D2E38F2C4540D1DEA.session”，而存放目录路径则由ServletContext.TEMPDIR变量指定，一般默认目录路径为”%CATALINA_HOME%/work/Catalina/localhost/web’name/”，其实就是”tomcat安装根目录+work+engineName+hostName+contextName”。所以假如有一万个会话则会有一万个会话文件。为了方便操作写入直接使用jdk自带的java.io.ObjectOutputStream对会话对象进行序列化并写入文件，所以有一点需要注意的是所有会话中的对象必须实现Serializable接口。

类似的，加载会话是通过传入一个sessionId，拼装成sessionId+”.session”格式的文件名去找对应的会话文件，然后使用jdk自带的java.io.ObjectInputStream将会话对象载入内存中，其实就是一个反序列化过程。

配置文件可以按如下配置：

如果配置了directory，则将以”%CATALINA_HOME%/work/Catalina/localhost/web’name/sessiondir”为存放目录，当然如果配置为绝对路径则以你配置的绝对路径为存放目录。

以FileStore为存储设备使用时看起来在文件操作IO上效率相当低，因为对每个文件操作都是打开-操作-关闭，并未使用任何优化措施，所以tomcat在选择使用此方式时这里很可能会成为影响整体性能的一个点，必须要做好充分的性能测试。

 

5.2 JDBCStore

JDBC存储设备提供的是以数据库形式存放会话，后端可以是任意厂商的数据库，只要有对应的数据库驱动程序即可。既然要存放数据肯定就要先在数据库中创建一张会话表，表的结构必须要tomcat与mysql双方约定好，例如tomcat默认的表名为”tomcat$sessions”，表字段一共有6个，分别为”app”、”id”、”data”、”valid”、”maxinactive”、”lastaccess”，app字段用于区分哪个web应用，id字段即会话标识，data字段用于存放会话对象字节串，valid字段表示此会话是否有效，maxinactive字段表示最大存活时间，lastaccess字段表示最后访问时间。其中需要注意的是data字段，由于它的大小直接影响会话对象的大小，所以需要根据实际设置它的类型，如果是mysql可以考虑设置为Blob（65k）或MediumBlob（16m）。

这样一来，会话的加载和保存其实就转化为对数据库的读写操作了，而获取数据库连接的逻辑是先判断tomcat容器中是否有数据源，如果有则从数据源中直接获取一条连接使用，但是如果没有的话则会自己通过驱动去创建连接，需要注意的是从数据源中获取的连接在使用完后会放回数据源中，但自己通过驱动创建的连接使用完则不会关闭，这个很好理解，因为数据源是一个池，重新获取连接很快，而自建的连接重新创建一般需要秒级别的消耗，明显会造成大问题。

下面以mysql数据库为例配置一个JDBC存储设备：

    

       connectionURL="jdbc:mysql://localhost:3306/web_session?user=user&password=password"

       driverName="com.mysql.jdbc.Driver"

       sessionAppCol="app_name"

       sessionDataCol="session_data"

       sessionIdCol="session_id"

       sessionLastAccessedCol="last_access"

       sessionMaxInactiveCol="max_inactive"

       sessionTable="tomcat_sessions"

       sessionValidCol="valid_session" />

其中关于会话表及其字段的一些属性可以不必配置，直接采用tomcat默认的即可，但驱动程序及连接url则一定要配置。

以JDBCStore为存储设备时从表面看起来并不会有明显的IO性能问题，因为它使用数据源获取连接，是一种池化技术，就算不存在数据源也是采用长久连接模式，一般数据流不是非常大的话都不会存在性能问题。

整个介绍完存储设备store后接着看持久化会话管理器，其实持久化会话管理器主要实现的就是三种逻辑下的对会话进行持久化操作，①当会话对象数量超过指定阀值时则将超出的会话对象转换出（保存到store中并把内存中的此对象删除）到store中；②当会话空闲时间超过指定阀值时则将此会话对象换出；③当会话空闲时间超过指定阀值时则将此会话进行备份（保存到store中并且内存还存在此对象）。

实现上面的逻辑只需对所有会话集合进行遍历即可，把符合条件的通过store保存。由于有些会话被持久化到store中，所以通过id查找会话时需先从内存中查找再往store查找。

下面是一个配置例子，会话数大于1000时则将空闲时间大于60秒的会话转移到store直到会话数量控制在1000，超过120秒空闲的会话被换出到store，超过180秒空闲的会话将备份到store。

    maxActiveSessions="1000"

    minIdleSwap="60"

    maxIdleSwap="120"

    maxIdleBackup="180">

    

 

所以在了解了两种Store后对持久化会话管理器的实现原理机制就相当清楚了，其实就是提供两种会话保存方式并提供管理这些会话的操作，它提高了tomcat状态处理相关方面的容错能力得到提升。

 

6. 集群增量会话管理器——DeltaManager

DeltaManager会话管理器是tomcat默认的集群会话管理器，它主要用于集群中各个节点之间会话状态的同步维护，由于相关内容涉及到集群，可能会需要一些集群通信相关知识，如果有疑问可结合集群相关章节。

集群增量会话管理器的职责是将某节点的会话该变同步到集群内其他成员节点上，它属于全节点复制模式，所谓全节点复制是指集群中某个节点的状态变化后需要同步到集群中剩余的节点，非全节点方式可能只是同步到其中某个或若干节点。在集群中全节点会话复制的一个大致步骤如下图所示，客户端发起一个请求，假设通过一定的负载均衡设备分发策略分到其中一个结点node1，如果还未存在session对象的话web容器将会创建一个会话对象，接着执行一些逻辑处理，在对客户端响应之前有个重要的事情是要把session对象同步到集群中其他节点上，最后再响应客户端。当客户端第二次发起请求时，假如分发到node3节点上，由于同步了node1的session会话，所以在执行逻辑时并不会取不到session的值。如果删除某个会话对象则要同时通知其他节点把相应会话删除，如果修改了某个会话的某些属性也同样要更新到其他节点的会话中。

 

 

DeltaManager其实就是一个会话同步通信解决方案，除了具备上面提到的全节点复制外，它还有具有只复制会话增量的特性，增量是以一个完整请求为周期，即会将一个请求过程中所有会话修改量在响应前进行集群同步。往下看Tomcat具体实现方案。

为区分不同的动作必须要先定义好各种事件，例如会话创建事件、会话访问事件、会话失效事件、获取所有会话事件、会话增量事件、会话ID改变事件等等，实际上tomcat集群会有9种事件，集群根据这些不同的事件就可以彼此进行通信，接收方对不同事件做不同的操作。如下图，例如node1节点创建完一个会话后，即向其他三个节点发送EVT_SESSION_CREATED事件，其他三个节点接收到此事件后则各自在自己本地创建一个会话，会话包含了两个很重要的属性——会话ID和创建时间，这两个属性都必须由node1节点跟着EVT_SESSION_CREATED一起发送出去，本地会话创建成功后即完成了会话创建同步工作，此时你通过会话ID查找集群中任意一个节点都可以找到对应的会话。同样对于会话访问事件，node1向其他节点发送EVT_SESSION_ACCESSED事件及会话ID，其他节点根据会话ID找到对应会话并更新会话最后访问时间，以免被认为是过期会话而被清理。类似的还有会话失效事件（同步集群销毁某会话）、会话ID改变事件（同步集群更改会话ID）等等操作。

 

 

 

Tomcat使用SessionMessageImpl类定义了各种集群通信事件及操作方法，在整个集群通信过程中就是按照此类定义好的事件进行通信，SessionMessageImpl包含的事件如下{ EVT_SESSION_CREATED、EVT_SESSION_EXPIRED、EVT_SESSION_ACCESSED、EVT_GET_ALL_SESSIONS、EVT_SESSION_DELTA、EVT_ALL_SESSION_DATA、EVT_ALL_SESSION_TRANSFERCOMPLETE、EVT_CHANGE_SESSION_ID、EVT_ALL_SESSION_NOCONTEXTMANAGER }，除此之外它继承了序列化接口（方便序列化）、集群消息接口（集群的操作）、会话消息接口（事件定义及会话操作）。

 

 

集群增量会话管理器DeltaManager可以说是通过SessionMessageImpl消息来管理DeltaSession，即根据SessionMessageImpl里面的事件响应不同的操作。Tomcat的集群通信使用的是tribes组件（相关章节会对tribes组件详细分析），网络IO都交由tribes后应用可以更专注逻辑处理，DeltaManager存在一个messageDataReceived(ClusterMessage cmsg)方法，此方法会在本节点接收到其他节点发送过来的消息后被调用，且传入的参数为ClusterMessage类型，可转化为SessionMessage类型，然后根据SessionMessage定义的9种事件做不同处理。其中有一个事件需要关注的是EVT_SESSION_DELTA，它是对会话增量同步处理的事件，某个节点在一个完整的请求过程中对某会话相关属性的所有操作被抽象到了DeltaRequest对象中，而DeltaRequest被序列化后会放到SessionMessage中，所以EVT_SESSION_DELTA事件处理逻辑就是从SessionMessage获取并反序列化出DeltaRequest对象，再将DeltaRequest包含的对某个会话的所有操作同步到本地该会话中，至此完成会话增量同步。

 

 

DeltaManager就是DeltaSession的管理器，它提供了会话增量的同步方式而不是全量同步，极大提高了同步效率。

 

7.集群备份会话管理器——BackupManager

全节点复制的网络流量随节点数量增加呈平方趋势增长，也正是因为这个因素导致无法构建较大规模的集群，为了使集群节点能更加大，首要解决的就是数据复制时流量增长的问题，于是tomcat提出了另外一种会话管理方式，每个会话只会有一个备份，它使会话备份的网络流量随节点数量的增加呈线性趋势增长，大大减少了网络流量和逻辑操作，可构建较大的集群。

7.1 机制与原理

正常情况下为了支持高效的并发操作，tomcat的所有会话集使用ConcurrentHashMap结构保存，String类型是指SessionId，MapEntry则是对session、源节点成员及备份节点等的封装（详细的类结构如下图所示，备份节点虽然为数组类型，但实际情况我们只会设置一个备份节点），一般session对象由哪个节点生成则哪个节点为源节点，备份节点则为集群中其他任意一节点，所以MapEntry可以看成是包含了源节点和备份节点信息的会话对象。会话管理器其实就是对会话集操作的封装，从设计角度看，为了改变会话集的操作行为，只需继承ConcurrentHashMap类并重写其中一些方法即可实现，例如put、get、remove等等操作实现跨节点操作。于是tomcat的BackupManager对整个会话集的跨节点操作被封装到一个继承ConcurrentHashMap类的LazyReplicatedMap子类中，而要实现跨节点的操作要做的事很多，例如备份节点列表的维护、备份节点选择、通信协议、序列化&反序列化及复杂的IO操作等等，弄清楚了LazyReplicatedMap的工作原理也就基本清楚BackupManager如何工作。

【源节点、备份节点、代理节点】

下面看看这种方式具体的工作机制，集群一般是通过负载均衡对外提供整体服务，所有节点被隐藏在后端组成一个整体。前面各种模式的实现都无需负载均衡协助，所以图中都把负载均衡省略了。最常见的负载方式是前面用apache拖所有节点，它支持将类似“326257DA6DB76F8D2E38F2C4540D1DEA.tomcat1”的会话id进行分解，定位到tomcat集群中以tomcat1命名的节点上（这种方式称为Session Stick，由apache jk模块实现）。每个会话存在一个原件和一个备份，且备份与原件不会保存在同一个节点上，如下图，例如当客户端发起请求后通过负载均衡被分发到tomcat1实例节点上，生成一个包含.tomcat1后缀的会话标识，并且tomcat1节点根据一定策略选出此次会话对象备份的节点，然后将包含了{会话id，备份ip}的信息发送给tomcat2、tomcat3、tomcat4，如图中虚线所示，这样每个节点都有一个会话id、备份ip列表，即每个节点都有每个会话的备份ip地址。

接着分析Tomcat对上面机制详细的实现，正常情况下为了支持高效的并发操作，tomcat的所有会话集使用ConcurrentHashMap

public Object put(Object key, Object value) {

  ①实例化MapEntry，将key和value传入，并设置源节点为目前节点。

  ②判断本地内存是否已包含key，如是则不仅要本地remove掉，还要跨节点remove。

  ③通过Round robin算法从MapMember中选择一个作为备份节点。

  ④实例化一个包含MSG_BACKUP标识的MapMessage对象并发送给备份节点。

  ⑤实例化一个包含MSG_PROXY标识的MapMessage对象并发送给除了备份节点外的其他（代理）节点。

  ⑥put进本地缓存。

}

其次，再看看它如何通过get实现获取会话对象操作：

public Object get(Object key) {

 ①获取本地的MapEntry对象，它或许直接包含了会话对象，或许包含了会话对象的存放位置信息。

 ②判断本节点是否属于源节点，如为源节点则直接获取MapEntry对象里面的会话对象并返回。

 ③判断本节点是否属于备份节点，若为备份节点则直接获取MapEntry对象里面的会话对象作为返回对象，并且还要将本节点升为源节点、重新选取一个新备份节点，把MapEntry对象拷贝到新备份节点。

 ④判断本节点是否属于代理节点，若为代理节点则向其他节点发送会话对象拷贝请求，“集群中谁有此会话对象请发送给我”，把接收到的会话对象放到本节点并作为返回对象，最后将本节点升为源节点。

}

最后，看看删除会话对象remove操作的实现：

public Object remove(Object key) {

 ①删除本地此MapEntry对象。

 ②广播其他节点删除此MapEntry对象。

}

 

7.2 高可用性以及故障转移机制

集群要提供高可用性就必须要有某种机制去保证。常用的机制为故障转移，简单地说，就是通过一定的心跳检测是否有故障，一旦故障发生，备份节点则接管故障节点的工作。

下面介绍BackupManager实现故障转移能力。

使用BackupManager管理会话必须要有负载均衡器，它提供会话黏贴（Session Stick）机制。所谓的会话黏贴其实是一种会话定位技术，即在Tomcat节点上生成一种包含位置信息的会话ID，它一般附带了Tomcat的实例名称，当客户端再次的请求的时候，负载均衡器会解析会话ID中的位置信息并转发到响应的节点上。

7.3 集群RPC通信

RPC即远程过程调用，它的提出旨在消除通信细节，屏蔽复杂并且易错的底层网络通信操作，像调用本地服务一般的调用远程服务，让业务开发者更多的关注业务开发，而不必考虑网络、硬件、系统的异构复杂环境。

         同样在Tomcat集群中会话对象互相复制会涉及各种逻辑处理以及网络I/O操作。为了避免重复的网络通信编码以及方便更加关注上层逻辑处理，在会话同步组件中提供了RPC方式供集群各节点之间通信，例如做心跳测试，向集群广播请求后只接受第一个应答节点的信息；

 

8.Tomcat会话管理器的集成

Tomcat中所有的会话管理器包括标准的会话管理器、持久化会话管理器、集群增量会话管理器、集群备份会话管理器。它们为用户提供了各种功能的会话管理器，有非持久化模式的，也有持久化模式的，有集群全量复制模式的，也有集群备份模式。

         在不同场景中，用户根据实际情况可以选择不同的会话管理器。为了方便使用，需要提供一种简易的方法，Tomcat提供的是配置方式，只需要通过对配置文件进行配置即可完成对会话管理器的选择。

在程序层面上，为了让会话管理器实现可配置化，它需要定义一个统计的管理接口——Manager接口。

在Tomcat的server.xml中可以实现对这四种会话管理器的配置；