Resin Session AnalysisWritten by Wooce 1. Resin的Reliability和Load balance机制Resin在Web Server中的内嵌模块处理请求的顺序:1)Web Server接收到请求2)内嵌模块(mod_caucho, mod_isapi等)检查是否由Resin处理的请求3)内嵌模块选中一个后台JVM,也就是一个<srun>:a.如果是已有的session, 则选中拥有该session的那一个JVMb.如果是新的请求,则采用轮循策略交由下一个<srun>处理4)内嵌模块通过TCP Socket把请求发给选中的后台JVM5)内嵌模块再通过同一TCP Socket连接接收后台JVM的响应结果.所有的有关内嵌模块和后台JVM均在resin.conf这一配置文件中配置, 使维护变得容易.因为内嵌模块需要决定选用哪一个JVM,所以负载平衡由内嵌模块控制.从JVM的角度看,来自内嵌模块的请求和HTTP请求是同样的,除了编码稍有不同.例如, Resin1.2或以上,同一个JVM可以在同一个端口8080同时作为srun和httpd服务器服务.轮循策略虽然简单, 但它实际上和其他复杂的负载平衡测率一样有效, 并且正由于简单, 它更加健壮和快速.1.1单机最廉价的备份策略. 它在单台机器上运行一个Web Server和两个JVM. 其中一个是主服务JVM, 另一个是后备JVM, 如果主JVM失效, 将启用后备JVM维持Servlet Engine仍然可用. 在resin.conf中的相应配置例子:启动时应该分别单独地启动这两个sun进程. 例如unix下:在NT下:1.2单Web Server, 多JVM当有多台计算机的时候, 可以把负载分担到一台Web Server和多个JVM上, 这比用路由器实现负载平衡较为廉价. 并且采用Resin自己的负载平衡机制,可以保证使同一个session 停留在同一台计算机上.配置举例:各台计算机可以共享使用同一个resin.conf, 但也可以为Web Server和每个JVM分别使用不同的resin.conf.为了确保session停留在固定的机器上, Resin对cookie的编码中加上了主机号标识. 1.3多Web Server和JVM对于大型的服务网站, 一般使用多台计算机, 并且每台计算机都分别运行一个Web Server和一个JVM, 由Router负责把负载分担到不同的机器上.对于这种方法, 由于Router随机地把负载分配到某台机器上, 所以发给某台host的请求的Session不一定是这台Host拥有的.因此需要把任何持久的session维护在一台中央服务器如JDBC数据库上或者采用其他方法使能够由session的id找到拥有该session的机器.即使对于这种Router负载平衡方法, 仍然可以用Resin自己的load balance策略提高可靠性. 对于每一台host上的web server, 都应该首先使用同一台host上运行的JVM进行处理, 但同时可以另一台Host上运行的JVM作为后备.上面例子中host1, host2,host3上的JVM只有当localhost上的JVM失败时才会被启用.另一个例子:1.4多Web Server, 单JVM多个Web Server可以同时使用同一个JVM处理请求. 例如, 我们有一个高速的一般的Web Server和一个采用SSL加密的Web Server的时候, 这两个Web Server可以由同一个JVM 处理请求(虽然如果有一个后备JVM的话会更好), 这简化了引入SSL的开发.2. Resin内部实现distributed sessions的机制2.1 session的backing store的概念和内存中的session的同步更新在Resin设置成load balance over multiple machine的情况, 各台运行web server和JVM 的机器组成一个load balancing pool.为实现load balance over multiple machine下的distributedsession, 必须考虑一个session在被生成后, 在load balancing pool中其他不拥有该session的机器如何访问它, 以及如何同步它们. 在Resin中是通过把session存储到backing store中来解决的, 一个JVM创建了一个新的session后,就把它存储到backing store去, 然后只要保证以下条件:(1)每个内存中有此session的JVM如果更新了此session, 就把更新后的session写到backing store中去, 并且backing store里做到在写某一session的时候不会同时接受读取同一session的请求.(2)每个JVM在读取session的时候,如果它的内存cache中还没有该session, 一定到backing store去读取.(3)某个JVM: Server A在读取session的时候,如果它的内存cache中已有该session, 这时只要满足以下的其中一种情况即可:a. 在(1)中写session到backing store里时保证同时更新了Server A的内存cache中的sessionb. 到backing store中再load出session并以此更新内存cache中的session显然, 满足了以上3个条件, 不同的机器存取同一session的时候就有很好的同步性, 并且亦有较好的性能.在Resin中, backing store可采用3种实现方式: (参看src/com/caucho/server/http/下的SessionStore.java,SessionFileStore.java,SessionJdbcStore.java和SessionRingStore.java)(1)SessionFileStore(这一方式在我所看的Resin2.0.2的代码里实际上还未实现)session的backing store在生成它的Host的文件系统(Resin似乎考虑在将来实现一个在不同的运行JVM的机器之间共享文件的网络文件系统VFS)上.(2)SessionJdbcStore在一台中央服务器上的database作为backing store, 每台Host上生成的session都通过JDBC存储到中央服务器的database中去.(3)SessionRingStore在这种方式中, load balancing pool中所有的运行JVM的机器按host id从小到大(host id 的首字母从’a’到’z’的顺序)组成一个JVM的index号的环, 当环中的某一台Host生成了一个session(session里记录了生成它的JVM的index号)的时候, 就以生成该session的JVM的index号开始, 在环上顺序查找, 只要某一个index的JVM是可用的, 就把session存储到运行该JVM的机器的本地文件系统中, 这样在两台机器上都分别存储了这个session的副本的时候就停止. 明显可看出, 一般情况下(所有JVM都没有crash down)每个session都有两个副本分别存储在生成它的那台机器和环中的下一台机器的文件系统中.Resin采用上述3种方式中的哪种方式来实现distributed session决定于:IF resin.conf中session-config/file-store和其下的directory的tag不为空THEN 采用SessionFileStore;ELSE IF resin.conf中session-config/tcp-store为true THEN 采用SessionRingStore;ELSE IF resin.conf中session-config/jdbc-store不为空THEN 采用SessionJdbcStore;在Resin的实现中,(1)SessionRingStore方式一定能满足上面所说的3个条件, 同步性最好.而对于(2)SessionFileStore和SessionJdbcStore两种方式a. 当resin.conf中session-config/always-load-session为false的时候, 如果一个JVM读入了session在内存cache中, 以后除非timeout再从backing store中reload的情况, 以后有请求都一定从内存cache中读该session, 不能看到其他JVM在此期间对该session 的更新, 这时同步性最差, 但由于不需从backing store中读取, 响应速度最快;b. 当resin.conf中session-config/always-load-session为true的时候, 这时任何请求都会到backing store中读取, 同步性好, 但由于session的内存cache实际上不起作用, 对请求的响应速度最慢.2.2 相关类分析2.2.1 QSession类实现HttpSession接口, 在Resin系统中某个JVM内存中的session就是一个QSession对象, JVM内存cache中的QSession对象需要和backing store中的session保持同步更新.2.2.2 VirtualHost类在一个JVM上处理的所有Servlet application的集合.2.2.3 SrunConnection类维护本JVM到另一个JVM的一个用以交换session的socket连接.2.2.4ServletServer类实现Server接口其他:hostList: ArrayList类型(VirtualHost对象)addHost(String id, RegistryNode node, String appDir)函数:根据(id, node, appDir)新建一个VirtualHost对象并存入HashTable类型成员hosts中.init()函数:初始化invocationCache(LRUCache类型)等内存中的Cache;调用initHosts()函数初始化hosts 等;2.2.5 SessionStore类负责session的访问(读取/存储)操作的基类, SessionFileStore,SessionJdbcStore, SessionRingStore等都是它的子类.2.2.5SessionBacking类封装session存储在file system上的backing path上时的访问操作的接口.2.2.6 SessionManager类管理一个servlet application的所有session重要数据成员和函数:2.2.6SessionRingStore类当以Ring方式的backing store存储distributed sessions时SessionStore类的实现.SessionRingStore.java的void store(QSession session)函数:int sessionIndex = session.getSrunIndex(); //生成该QSession对象的JVM的index号int srunIndex = manager.getSrunIndex(); //执行本函数的JVM的index号int srunCount = manager.getSrunCount(); //Load balancing pool中所有JVM的数目if (sessionIndex < 0)sessionIndex = srunIndex;int index = sessionIndex; //在环中从生成该QSession对象的JVM的index号开始ReadWritePair rws = null;boolean hasSelf = false;int saveCount = 2; //分别存储2个副本到2个JVM的file system中for (int i = srunCount - 1; i >= 0 && saveCount > 0; i--) {//在环上查找一周,并且成功存//储2个副本时就停止if (index == srunIndex) { //环上的当前index号是本机的index号, 令hasSelf为truehasSelf = true; //使在后面的代码段中将会调用StoreSelf()函数存储Session副saveCount--; //本到本机的file system中}else {rws = server.getRecycleConnection(index); //环上当前检查的index号是其他机器,if (rws != null) { //取出可用的socket连接把QSession对象传给index号host让它try { //存储或更新到它的本地file sytem(由RunnerRequest.java处理) saveSession(tempStream, backing.getId(), index, rws);saveCount--;} catch (IOException e) {rws.getReadStream().close();rws.getWriteStream().close();rws = null;}}if (rws == null) {rws = server.getSessionConnection(index);if (rws != null) {try {saveSession(tempStream, backing.getId(), index, rws);saveCount--;} catch (IOException e) {rws.getReadStream().close();rws.getWriteStream().close();rws = null;}}}}index = (index + 1) % srunCount; //取环中的下一个JVM}if (hasSelf) {ReadStream is = tempStream.openRead(true);storeSelf(session, is); //存储session到本地file systemis.close();storeSelf()函数如下:private void storeSelf(QSession session, ReadStream is){SessionBacking backing = session.getBacking();synchronized (backing) { //通过异步synchronized避免多个请求时的写冲突try {Path sessionPath = backing.getPath(); //获得session在本地file system上的存储路径WriteStream os = sessionPath.openWrite();os.writeStream(is);os.close();} catch (IOException e) {if (dbg.canWrite())dbg.log(e);}}boolean load(QSession session)throws Exception{SessionBacking backing = session.getBacking();if (backing == null)return false;int sessionIndex = session.getSrunIndex();int srunIndex = manager.getSrunIndex();int srunCount = manager.getSrunCount();if (sessionIndex < 0)sessionIndex = srunIndex;int updateCount = session.getUpdateCount();/* servers A and B don't need auto-reloading, but server C does.这里server A和server B即指存有session副本的那两个server,当本JVM是server A或server B之一的时候, 显然本JVM的内存cache里的session 肯定是整个load balancing pool中最新的, 所以从这里退出来后回到SessionManager类//的QSession getSession(String key, long now)函数往下执行到else if (sessionStore != null && now > 0 &&(reloadEachRequest || session.needsLoad()))load(session, now);这里session.needsLoad()函数必须返回false, 反之不是server A和server B的情况session.needsLoad()函数就必须返回true以便调用load(session,now)从server A和server B 上获取最新更新的session, 所以在这里的符合条件判断时的代码段内有session.setNeedsLoad(true);语句*/if (srunIndex != sessionIndex &&(sessionIndex + 1) % srunCount != srunIndex) {updateCount = -1;session.setUpdateCount(-1);session.setNeedsLoad(true);}ReadWritePair rws = null;int index = sessionIndex;int loadCount = 2;// Find a live serverfor (int i = srunCount - 1; i >= 0 && loadCount > 0; i--) {try {if (srunIndex != index) {rws = server.getRecycleConnection(index);if (rws != null) {try {if (loadSession(session, index, backing.getId(),rws, updateCount)) {loadCount--;updateCount = session.getUpdateCount();}} catch (IOException e) {rws.getReadStream().close();rws.getWriteStream().close();rws = null;}}if (rws == null) {rws = server.getSessionConnection(index);if (rws != null &&loadSession(session, index, backing.getId(),rws, updateCount)) {updateCount = session.getUpdateCount();loadCount--;}}}else if (loadSelf(session, updateCount)) {if (dbg.canWrite()) {dbg.log("[" + server.getServerId() + "] self-load(" + index + ") " +backing.getId() + " " + backing.getPath());}updateCount = session.getUpdateCount();loadCount--;}} catch (Exception e) {if (dbg.canWrite())dbg.log(e);}if (srunCount > 1)index = (index + 1) % srunCount;return loadCount < 2 && updateCount > 0;}2.3 对Session的处理流程2.3.1 新的请求(需要新生成一个原来在backing store中没有的session)的情况当有新的请求时,1) 执行Request.getSession(boolean create=true) (指调用Request类的getSession(Boolean create)函数, 并传参数create为true,下同) .2) Request.getSession(boolean create)调用AbstractRequest.createSession(boolean create, boolean hasOldSession)函数.3) AbstractRequest.createSession(boolean create, boolean hasOldSession)最后调用SessionManager.createSession(String oldId, long date, int sessionGroup,HttpServletRequest request)创建QSession对象(但只在内存中, 并未存储到backing store)4) 对Request的处理完成, 调用Request.finish().5)Request.finish()调用QSession.finish().6)QSession.Finish()调用SessionStore.Store(QSession Session)完成将session存储到backing store的过程.2.3.2对旧有Session的请求(backing store中存在此id的session)的情况1)执行Request.getSession(Boolean create=false)2)Request.getSession(boolean create)调用AbstractRequest.createSession(boolean create,boolean hasOldSession).3)AbstractRequest.createSession(boolean create, boolean hasOldSession)调用SessionManager.getSession(String key, long now)4)SessionManager.getSession(String key, long now)在内存Cache中查找此QSession对象, 如果需要reload, 还要从backing store中读取QSession对象的更新的值, 然后返回QSession对象.2.3.3非法请求(整个系统中不存在此id的session)的情况在Request类中的boolean isRequestedSessionIdValid()函数即能判断, 它将调用Request.getSession(false)在本JVM的内存cache和backing store中查找此id的session, 如果都找不到则返回false.附AbstractRequest.java的createSession(boolean create, boolean hasOldSession)函数的注解: protected QSession createSession(boolean create, boolean hasOldSession){Application application = getApplication();SessionManager manager = application.getSessionManager();String id = getRequestedSessionId(); //读取请求中发过来的session idlong now = Alarm.getCurrentTime();QSession session;if (id != null && id.length() > 6) {session = manager.getSession(id, now); //从内存cache中读取此id的QSession对象, 没if (session == null) { //有则创建一个}else if (session.isValid()) //成功则返回该QSession对象return session;elseid = null;}if (hasOldSession)id = null;if (! create)return null;// Must accept old ids because different applications in the same// server must share the same cookie//// But, if the session group doesn't match, then create a new// session.session = manager.createSession(id, now, getSessionGroup(), this); //新建QSession对象if (session != null) //注意创建QSession对象和创建一个存储在backing store中//session不是一回事.setHasCookie();if (id != null)return session;if (manager.enableSessionCookies())getResponse().setSessionId(session.getId());return session; //返回新创建的QSession对象}。
